Re: [Cpu-users] Slow user creation

[Blake M. <bma...@pu...>]

Well, there are a couple of issues here to consider. If there is a large
userbase, grabbing all of the IDs could be terribly slow. If there isn't a
large user base, the problem is that the order in which users (or groups) are
returned is not by UID/GID, but rather by time of last modification (usually).
So as we are grabbing UIDs/GIDs, we would need to insert them into a binary
tree (or something similar), then search the tree. We could do this also with
a bitvector (which would likely be faster and smaller) but both take up extra
memory and time. I'll have to think about it.

Of course, setting MIN_UID to the MAX_UID in use would still allow for fast
linear searches as Eric suggested, but it's not ideal.

Ideas welcome.

-Blake

Whatchu talkin' 'bout, Willis?
> 
> That should but I would like both, linear and relatively quick.
> 
> CPU seems to do a lot of small searchs, could it not get the list of 
> UIDs in one go and then figure out the UID to use from there internally? 
> A cpu -w cat comes back in a little over 2 seconds on my system and only 
> makes one query to the directory rather than searching one entry at a 
> time to determine its relatively usefulness.
> 
> For example if you run the following you quickly get a sorted list of 
> all the existing UID's
> 
> cpu -w cat| awk -F : {'print $3'} | sort | uniq
> 
> Then just grab the last one, increment by one and you are done. I can do 
> this by hand of course but having CPU do it for me is nicer. :)
> 
> That would also avoid the need to cache the UID.
> 
> Terrence
> 

-- 
Blake Matheny           "... one of the main causes of the fall of the
bma...@pu...      Roman Empire was that, lacking zero, they had
http://www.mkfifo.net    no way to indicate successful termination of
http://ovmj.org/GNUnet/  their C programs." --Robert Firth