Re: [Pharo-project] Collection
Igor wrote:
If such kind of collections didn't existed over more than 30 years of smalltalk existance, what makes you think that there a big interest in having them today? Memory. Without the memory to use them, the need was not there. Of course, they could occupy some niche, but i doubt that they will replace an existing classes in a day-to-day use. In a 64 bit system, it is not a niche. You simply need a set of collection classes that work well with millions an tens of millions of elements, not just 100.000s. Besides, many projects implementing own kinds of collections, specific to their needs. That is exactly what you want to avoid. I've had to implement these collections too often.
Stephan
On 13 March 2010 13:24, Stephan Eggermont <stephan@stack.nl> wrote:
Igor wrote:
If such kind of collections didn't existed over more than 30 years of smalltalk existance, what makes you think that there a big interest in having them today? Memory. Without the memory to use them, the need was not there. Of course, they could occupy some niche, but i doubt that they will replace an existing classes in a day-to-day use. In a 64 bit system, it is not a niche. You simply need a set of collection classes that work well with millions an tens of millions of elements, not just 100.000s.
What you talking about is an edge case in currently existing systems. And its easy to prove: (OrderedCollection allInstances collect: [:each | each size ]) asBag sortedCounts {2956->0 . 1054->1 . 570->4 . 457->5 . 387->6 . 288->2 . 247->3 . 222->7 . 162->8 . 145->9 . 83->10 . 66->11 . 41->12 . 27->14 . 18->13 . 14->15 . 11->16 . 8->30 . 6->17 . 6->25 . 5->36 . 4->21 . 4->27 . 4->42 . 3->26 . 2->18 . 2->23 . 2->24 . 2->35 . 2->44 . 2->52 . 2->222 . 2->336 . 2->1352 . 1->20 . 1->22 . 1->32 . 1->33 . 1->34 . 1->38 . 1->43 . 1->48 . 1->53 . 1->69 . 1->73 . 1->74 . 1->89 . 1->90 . 1->100 . 1->120 . 1->121 . 1->129 . 1->131 . 1->133 . 1->137 . 1->158 . 1->167 . 1->177 . 1->190 . 1->197 . 1->198 . 1->206 . 1->219 . 1->231 . 1->232 . 1->278 . 1->293 . 1->312 . 1->317 . 1->354 . 1->359 . 1->372 . 1->394 . 1->412 . 1->482 . 1->565 . 1->605 . 1->640 . 1->670 . 1->680 . 1->694 . 1->751 . 1->872} and until this list will show a 5% or more presence of collections which having 100000 and more elements, i don't see a pressing need in doing something, because obviously, a current implementation which works fine for general cases. Or do you think that on 64 bit systems the above distribution will be different?
Besides, many projects implementing own kinds of collections, specific to their needs. That is exactly what you want to avoid. I've had to implement these collections too often.
So, what stopping you from creating a separate package, say CollectionsXL and add there a generalized versions of collections which optimized for working with extremely large datasets?
Stephan
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
participants (2)
-
Igor Stasenko -
Stephan Eggermont