Posted by GLASS mailing list on Jan 04, 2017; 2:19pm
URL: https://forum.world.st/Large-collection-and-common-practice-tp4928607p4928694.html

John,

The UUID can not be changed because is a data created in a Java application passed to GemStone as a parameter in a service.

regards

bruno

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 <[hidden email]> 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: 93b1205cec32b42993b9382a9b0d89046fd937c8

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
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

--

===========================================================================
John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk
===========================================================================

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

---

El software de antivirus Avast ha analizado este correo electrónico en busca de virus. www.avast.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass