Deprecate EnableRandPool and DisableRandPool about uuid HOT 3 OPEN

ping @pborman

from uuid.

The pool API looks pretty dangerous and unnecessary to me also.

The speed gain comes almost entirely from the buffered I/O, which did not require a new API. The remaining allocation is the UUID itself which could be improved in a generally-useful way by having a function to fill a received pointer:

func NewRandomFromReader(r io.Reader) (UUID, error) {
	var uuid UUID
	return uuid, ReadRandom(r, &uuid)
}

func ReadRandom(r io.Reader, uuid *UUID) error {
	_, err := io.ReadFull(r, uuid[:])
	if err != nil {
		return err
	}
	uuid[6] = (uuid[6] & 0x0f) | 0x40 // Version 4
	uuid[8] = (uuid[8] & 0x3f) | 0x80 // Variant is 10
	return nil
}

func BenchmarkUUID_NewBufio(b *testing.B) {
	b.RunParallel(func(pb *testing.PB) {
		r := bufio.NewReaderSize(rander, randPoolSize)
		for pb.Next() {
			_, err := NewRandomFromReader(r)
			if err != nil {
				b.Fatal(err)
			}
		}
	})
}

func BenchmarkUUID_ReadRandom(b *testing.B) {
	b.RunParallel(func(pb *testing.PB) {
		r := bufio.NewReaderSize(rander, randPoolSize)
		var uuid UUID
		for pb.Next() {
			err := ReadRandom(r, &uuid)
			if err != nil {
				b.Fatal(err)
			}
		}
	})
}

BenchmarkUUID_NewBufio-4    	 6769986	       176.0 ns/op	      16 B/op	       1 allocs/op
BenchmarkUUID_ReadRandom-4   	 7622210	       155.6 ns/op	       0 B/op	       0 allocs/op

These are also lock-free (or as lock-free as the reader allows) approaches. On my system ReadRandom consistently beats NewPooled, I assume because of less lock contention.

from uuid.

As mentioned i a code review, these should be limited to package main. Libraries that want a different generator should call a different function. The good new is, that unlike Version 1 UUIDs, Version 4 uuids can be safely generated by multiple packages. Version 1 UUIDs are based on state and it is possible (though unlikely) for two packages to produce either the same UUIDs or UUIDs in which time goes backwards.

from uuid.