[Glass] Large collection and common practice

[John McIntosh via Glass]

Although UUID are used as unique keys, I find them to be rather wasteful,
and it takes time to hash, etc.

In a number of application I have found that pulling a 64bit
cryptographically random number, checking for uniqueness before use, and if
so using it as a primary 64 bit integer key reduces bloat and just better
for most access operations.

On Wed, Jan 4, 2017 at 6:23 AM, Smalltalk via Glass <
glass at lists.gemtalksystems.com> wrote:

> Dale,
>
> Is there any measure of from what size a Dictionary could have this
> problem ? Maybe it also depends in the length of the key...
>
> (if the problem arise from 1.000.000 entries in a dictionary --> is not a
> problem for me right now)
>
> The keys of my Dictionary is an UUID like: 93b1205cec32b42993b9382a9b0d89
> 046fd937c8
>
> At this stage i think i will use 2 Rc collections (one dictionary + one
> bag) in the future maybe this approach has to be changed...
>
> For now i will keep it simple !
>
> regards
>
> bruno
>
> El 03/01/2017 a las 17:46, Dale Henrichs escribió:
>
>>
>> As the size of the collections gets very large, you have to keep in mind
>> that Dictionary-based structures have to be rebuilt periodically to keep
>> the collision bucket size manageable and some of the dictionaries like
>> RcKeyValueDictionary will rebuild automatically on insertion and depending
>> upon the size of the dictionary that could lead to long and unpredictable
>> delays for end users ... the btree structures used in GemStone indexes do
>> splits and merges on individual leaf nodes limiting the cost of insertions
>> ...
>>
>
>
> ---
> El software de antivirus Avast ha analizado este correo electrónico en
> busca de virus.
> https://www.avast.com/antivirus
>
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>



-- 
===========================================================================
John M. McIntosh. Corporate Smalltalk Consulting Ltd
https://www.linkedin.com/in/smalltalk
===========================================================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20170104/7139bd15/attachment.html>