> On 19 May 2015, at 4:52 , Norbert Hartl <[email protected]> wrote: > > Henry, > >> Am 19.05.2015 um 13:06 schrieb Henrik Johansen <[email protected] >> <mailto:[email protected]>>: >> >> Hi! >> I made some (imho) improvements to the OID implementation, if someone with >> write access would find time to review/commit the attached package, I'd be >> grateful. >> >> The commit message: >> Make OID implementation more compatible with the description in >> http://docs.mongodb.org/manual/reference/object-id/ >> <http://docs.mongodb.org/manual/reference/object-id/>. >> >> - Use the UNIX epoch instead of Smalltalk epoch for timestamp part, store BE >> so it's pseudo-sortable by time (also, you can use getTimestamp() in mongo >> shell and get a sensible value) > > Agreed with unix epoch. The old value was in BE also which seems to be the > right choice. > >> - Use a per-session ID instead of localhost name for machine identification. >> localhost name is far from unique on some platforms (always 'localhost' on >> Macs), better with a unique ID per image session. > > I do not agree. "NetNameResolver localHostName" does not return localhost for > me. And I'd rather think the NetNameResolver does not work properly on Macs > (not returning gethostname) instead of taking it as a reason to tweak client > code.
Hmm, yes, it seems localHostName could be implemented better in a way that works on all platforms. Instead of using the dedicated primitives (primHostNameSize/primHostNameResult:), it tries to lookup the localHostAddress using DNS... On OSX, primLocalAddress was changed to always return the loopback address so one avoids ambiguities with multiple interfaces, thus, 'localhost'. I've commit a fixed version to the Pharo 4.0 inbox. I still don't really see the value in using it over a random number that changes when the image goes through a restart cycle, as you can't really do anything useful with it anyways, and the docs do not enforce any specific way of obtaining it. > The id per Session wouldn't have any value because there is also a process id > which gives you more or less the same thing. Just to be clear; when I said session, I meant image session, not db-connection session. My thinking was that, when you can't actually use it to distingush clients anyways, a somewhat-guaranteed-to-be-unique machine id per image would be a better choice than guaranteed-to-be-identical for all users on Macs. > >> - Counter initialized with a random value. >> > Good idea. A bit more effort to do this if we stick to localHostName, as I piggybacked on the unused random bits in the UUID used to replace machineIdentifier for that, the other ways of getting random numbers in a cross-platform manner is rather hit-and-miss, both wrt quality and performance. > >> As an added bonus, [OID new] bench should see a ~10% increase in >> performance. >> > Even better. :) > > What do you think? > > I can make you a commiter on the MongoTalk repo. What's your username? henriksp is my user name. I tinkered some more, at the cost of readability, additional optimizations (by removing temporary object creations), can result in an order of magnitude more executions during a simple #bench test. Whether one actually needs to create 200k UIDs/second instead of 20k is another question, but in my experience, DB-interfaces can never be *too* low overhead... Cheers, Henry
