- Pharo-dev - lists.pharo.org

Re: [Pharo-project] vm on ubuntu

by Schwab,Wilhelm K

Doru, My machine is busy with an upgrade to 9.10 as I type, so I won't be able to check this for a while. IIRC, there at least was an entry for Squeak in the package manager. It was perhaps a couple of years ago that I used it; it worked well, but the version of Squeak that was installed was dated even at the time. See the message I just posted about using a shell script for another option. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Tudor Girba Sent: Saturday, October 31, 2009 8:56 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] vm on ubuntu Hmm, I get the following error: >>>>sudo apt-get install squeak-vm Reading package lists... Done Building dependency tree Reading state information... Done E: Couldn't find package squeak-vm I am running on Ubuntu 8.04.3 LTS. Doru On 31 Oct 2009, at 14:31, Lukas Renggli wrote: >> What is the preferred way to install a Pharo vm on Ubuntu? > > The instructions in the Seaside book should work: > > http://book.seaside.st/book/advanced/deployment/deployment-apache/inst > all-vm > > Did you try that? > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Every thing has its own flow." _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 31, 2009

Re: [Pharo-project] vm on ubuntu

by Tudor Girba

Hmm, I get the following error: >>>>sudo apt-get install squeak-vm Reading package lists... Done Building dependency tree Reading state information... Done E: Couldn't find package squeak-vm I am running on Ubuntu 8.04.3 LTS. Doru On 31 Oct 2009, at 14:31, Lukas Renggli wrote: >> What is the preferred way to install a Pharo vm on Ubuntu? > > The instructions in the Seaside book should work: > > http://book.seaside.st/book/advanced/deployment/deployment-apache/install-vm > > Did you try that? > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Every thing has its own flow."

Oct. 31, 2009

Re: [Pharo-project] Fwd: Adding FasterSets to Pharo: update

by Nicolas Cellier

2009/10/31 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Thanks. I push the discussion to pharo since lot of people are > interested. > > Stef > > Begin forwarded message: > >> From: Ralph Boland <rpboland(a)gmail.com> >> Date: October 29, 2009 11:43:04 PM GMT+01:00 >> To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> Cc: Levente Uzonyi <leves(a)elte.hu> >> Subject: Adding FasterSets to Pharo: update >> >> I took a look at FasterSets and Levente Uzonyi's version. >> I compared the two versions as of the first release of Levente's >> version to Squeak. Â Note that he has released additional >> changes since then. >> Here is my report. >> >> 1) Â Bugs: >> >> Â Â FasterSets has two problems: >> Â Â Â a) Â KeyedIdentitySet is missing method Â ScanForNil: >> Â Â Â b) Â PluggableSet is missing method Â NoCompareOrGrowAddAll: >> Â Â Both cases should cause failure. Â Note that I have been using >> Â Â this code for years without problem. Â I assume that is because >> the subset >> Â Â of Squeak that I used doesn't include using these classes. >> Â Â These problems are easily fixed. >> >> Â Â In Levente's code class WeakKeyToCollectionDictionary->rehash >> seems to be >> Â Â missing. Â This appears to be a mistate to me but I will live it >> to Levente to explain >> Â Â it. Â The fix, if needed, is simple. >> >> 2) Code quality: >> Â Â For me the code quality is about the same but Levente considers >> his version to be better. >> Â Â In any case changes in one version is easily ported to the other >> so it would be easy to >> Â Â perform any cleanup you might want. Â Three notes in particular. >> Â Â Â a) Â Levente's version of Â rehash is cleaner and should be used >> instead of mine. >> Â Â Â b) Â Levente's version does not use method Â scanForNilFrom: Â (He >> would probably call >> Â Â Â Â Â the method scanForEmptySlotFrom:). >> Â Â Â Â Â I don't know why he didn't do this: it clearly cleaner. >> >> Â 3 Performance. >> Â Â Â a) According to Levente's stats Â rehash is clearly faster in >> his version than mine. Â I see >> Â Â Â Â Â no reason no not prefer his version to mine. >> >> Â Â Â b) The improvement in performance for method add: Â in >> Levente's version >> Â Â Â Â Â is insignificant Â (appx 1%); Â this difference could easily >> be made up in minor >> Â Â Â Â Â changes to my code. Â Thus here I consider there to be no >> difference. >> >> Â Â Â b) Â Levente's version does not apply the FasterSets idea to >> MethodDictionary. >> Â Â Â Â Â I am not sure why he did not do this but it may have >> something to do with the fact that >> Â Â Â Â Â mistakes can easily corrupt your image. Â The version in >> FasterSets works fine though >> Â Â Â Â Â it took three tries for me to get it right (mostly because >> of carelessness). >> >> Â Â Â c) Â I left methods Â intersection and nastyAddNew: out of classes >> Set and Dictionary for >> Â Â Â Â Â Â the initial version of FasterSets to keep the number of >> changes to a minimum. >> Â Â Â Â Â Â At your request I added them to the current version. >> These methods are not in >> Â Â Â Â Â Â Levente's version. Â They are public methods that provide >> performance improvements. >> Â Â Â Â Â Â If desired they could easily be added to Levente's version. >> >> >> Based on the above I would Â say that there is not a great deal of >> difference between Levente's version and mine but what difference >> there is favors his version. >> >> I recommend that >> >> Â Â 1) Â You use Levente's version. >> Â Â 2) Â Sort out the issue of no rehash method for Class >> WeakKeyToCollectionDictionary. >> Â Â 3) Â Modify his code to use method scanForNilFrom: Â (calling it >> scanForEmptySlotFrom:). >> Â Â 4) Â Decide if you want to add methods Â intersect: and >> nastyAddNew:. >> Â Â Â Â Â I can add these if you want. >> Â Â 5) Release a version of Pharo with these changes. >> Â Â 6) Â In the following release of Pharo add the changes to >> MethodDictionary to use The >> Â Â Â Â Â FasterSets Idea. Â I sugggest doing this separately from >> everything else just because it is a >> Â Â Â Â Â bit hairy. Â I would not leave this change out because >> MethodDictionary is too important >> Â Â Â Â Â a class not to have these improvements. >> >> >> One final comment. Â If you really want to make the Set hierarchy >> better I would suggest that >> you move the Dictionary hierarchy out of the Set hierarchy >> altogether. Â This means some >> duplication of code but makes for a much cleaner implementation. Â For >> example you get to >> avoid the mess with MethodDictionary. Â Of the three implementations >> of Smalltalk that I >> have looked at Â Squeak/Pharo is the only version that uses one >> hierarchy. >> This is probably too major a change to make but at least you now know >> my opinion on the >> Â matter. >> You dont have to duplicate. You can just derive the two classes from a common HashedCollection ancestor. http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-June/117894.html Nicolas >> >> You can post this on the Pharo newsgroup if you like but perhaps you >> should get Levente's >> opinion first. >> >> Â Regards >> >> Â Ralph Boland > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 31, 2009

Re: [Pharo-project] vm on ubuntu

by Schwab,Wilhelm K

Not knowing what to make of Squeak vs. Pharo (or perhaps waiting until there is an Ubuntu package for the Pharo VM), I simply unpacked the vm under ~Software/PharoVM and launch Pharo with a shell script that lists the full path to the vm and the image. Then I added an icon to my Programming menu with the script as an action. If any of that is non-obvious to you, feel free to ask questions. I have done something similar on Windows for years to avoid the moods and bloat of the Windows Installer, so a script to specify the vm and image struck me as the preferred way to make it work. I have not yet started to run my own services on Linux, and what I am recommending might(??) lead to problems with ownership of the path. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Saturday, October 31, 2009 8:31 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] vm on ubuntu > What is the preferred way to install a Pharo vm on Ubuntu? The instructions in the Seaside book should work: http://book.seaside.st/book/advanced/deployment/deployment-apache/install-vm Did you try that? Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 31, 2009

Re: [Pharo-project] dictionary value is an array?

by Igor Stasenko

2009/10/31 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 2009/10/31 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >> Hi nicolas >> >> If I remember you proposed fixes to have dictionary values -> array? >> Is it correct? >> >> I was wondering why? >> Because a set makes more sense to me since >> Â Â Â Â - the order of the elements in values is not useful (because they >> come from a dict) >> Â Â Â Â - the occurrences not really either >> Â Â Â Â - we cannot add to the results so we should create another collection >> >> May be I'm totally wrong with the changes but I think that values >> should be set while keys an array. >> I would be interested in discussion on that. >> >> Stef >> >> > > Dictionary values is already an Array... > I proposed to change keys accordingly. > > Historically, they were a Bag and a Set because they were unordered. > > But very few or no sender expect a behavior specific to a Bag or a Set. > Most just do: select: collect: asArray asSortedCollection etc... > That's where an Array outperforms a Set or a Bag. > > So we are paying the price of a Set or a Bag almost for nothing... > And that is why you can see a #fasterKeys. > > The drawback is that a few senders will add: to or remove: from keys. > My estimation is around 5%. > Inside the image, no problem, it is easy to fix, just write > (someDictionary keys asSet). > But that put a load on package maintainers. > +1 Nicolas. Personally, i think that modifying a collection which not constructed by your own code is bad programming style, because you never know where this collection is came from and you can't be sure that there is no other users of it, which in own turn may modify it at any moment, while often you assuming that only you own the collection and don't expecting any modifications to it except in own code. So, IMO this approach is error prone, and you should never use #remove: or #add: with collections which constructed by separate package/layer, and instead, use #asSet, #asOrderedCollection and, of course #copy, before starting manipulating its elements. > Nicolas > >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Oct. 31, 2009

Re: [Pharo-project] Socket>>socketStream

by Schwab,Wilhelm K

Sig, An OO layer on top of procedural software does not have to be tied to the limitations of the procedural software, and in general should not be. You make refactoring of Socket sound like it can only be done by a complete slash and burn, when in fact it could be as simple as exposing behavior where it makes sense. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Friday, October 30, 2009 7:30 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Socket>>socketStream 2009/10/31 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Sig, > > Furthering a bad design practice does not illustrate an attempts to promote safe use of resources. Â If you knew that adding the behavior was a bad idea, why did you suggest it? > because, as to me, what you are proposing is equivalent to it. In smalltalk you can enforce the correct usage of provided functionality only by means of provided behavior. > Server behavior: consider listening on ports and accepting connections. Â True, that is BSD socket behavior, but you are trying to have it both ways. Â You cannot complain about superset behavior that I might introduce and then later say that the current design is ok because it uses the same shotgun wedding approach as BSD (aka a superset interface). > we have what we have. :) If you'd were writing own library for network communication which directly speaks with hardware (like in SqueakNOS), then you are free to do it differently. But Socket implementation depends on underlaying socket library, adopted by wide range of OSes working with wide range of hardware. It is good that we having something in common and don't need to invent or implement it from scratch. And despite how good or bad it is, it allows us to write portable software, including smalltalk, unless you refactor Socket class :) > Taking your approach, nothing in Squeak would ever get fixed. Â In fact, "well, YOU can always do such and such in YOUR image" was the usual argument used to block change in Squeak. Â Something to think about. > if there will be fix or extension in original socket library, only then we should consider synchronizing Socket class with it. > And yes, replacing the entire network system has crossed my mind. Â IPv4 and 6 are currently mixed into a big ball of mud (no offense to those working hard to add it, but it's not at all factored, and should be). Â I will hopefully soon be in a position to get network connections running across platforms, and I suspect that the errors reported some months ago will turn out to be due to the new sockets. Â Finally, we should have access to SSL sockets via OpenSSL. Â That might just drop in along side of the current socket system, but there might be room for a better solution, perhaps as an extension of Nile. > as long as you are using same library (sockets), i see not much reasons why we would need to drastically refactor the stuff. Because, with whatever code will wrap it, you end up using same system calls which expecting same argument types & returning same results. So, instead of 'better wrapper', we should expose these calls to language, as close as possible to original and this is the main role of Socket class. Then anyone is free to use them as he likes to. This is what i meant by talking about 'own subclass' and this is why i think that Socket class is bad place for refactory. My point is, that if you writing own library/classes, which having virtually no dependencies from other frameworks, then you are free to do it in any way you like to. But if your goal is to expose the functionality of existing library (such as sockets), then instead, you should be very pedantic and do it as much as close to original, despite how good or bad it is. Then you are opening doors to people who already used this library before, but in another environment/language. -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 31, 2009

Re: [Pharo-project] vm on ubuntu

by Lukas Renggli

> What is the preferred way to install a Pharo vm on Ubuntu? The instructions in the Seaside book should work: http://book.seaside.st/book/advanced/deployment/deployment-apache/install-vm Did you try that? Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Oct. 31, 2009

[Pharo-project] Fwd: MouseOverHandler

by StÃ©phane Ducasse

Begin forwarded message: > From: Hernan Wilkinson <hernan.wilkinson(a)gmail.com> > Date: October 29, 2009 2:02:32 PM GMT+01:00 > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Subject: MouseOverHandler > > Hi Stef, > do you know why the MouseOverHandler version I made is not in the > main image? the current version is not working well, under heavy use > it generates exceptions... > I'm attaching the version I wrote that I'm using without problem... > > Hernan.

Oct. 31, 2009

[Pharo-project] Fwd: Adding FasterSets to Pharo: update

by StÃ©phane Ducasse

Begin forwarded message: > From: Ralph Boland <rpboland(a)gmail.com> > Date: October 30, 2009 6:44:17 AM GMT+01:00 > To: Levente Uzonyi <leves(a)elte.hu> > Cc: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Subject: Re: Adding FasterSets to Pharo: update > > 2009/10/29 Levente Uzonyi <leves(a)elte.hu>: >> Hi! >> >> On Thu, 29 Oct 2009, Ralph Boland wrote: >> >>> In Levente's code class WeakKeyToCollectionDictionary->rehash >>> seems to >>> be >>> missing. This appears to be a mistate to me but I will live it >>> to Levente to explain >>> it. The fix, if needed, is simple. >> >> Only Set and MethodDictionary implements #rehash in the trunk >> version. >> #rehash sends #growTo: which sends #noCheckNoGrowFillFrom: which is >> implemented by WeakKeyToCollectionDictionary. >> > > The version of rehash in WeakKeyToCollectionDictionary is different > from the > other versions. I never bothered to figure out exactly what it does > and just > left it alone. Despite what you say my opinion is still that it is > needed but I will > leave it to those making the final decision to decide. > >>> b) Levente's version does not use method scanForNilFrom: (He >>> would probably call >>> the method scanForEmptySlotFrom:). >>> I don't know why he didn't do this: it clearly cleaner. >> >> It's called #scanForEmptySlotFor:, because WeakSet has a flag for >> empty >> slots, not nil. > > This is not correct. ScanForEmptySlotFor: is analogous to > scanForNil: You did > not implement a method analogous to scanForNilFrom: and obviously > never > used it either. In my opinion the use of scanForNilFrom: makes the > code cleaner > but it is not a major issue if it is not used. >> >>> b) The improvement in performance for method add: in Levente's >>> version >>> is insignificant (appx 1%); this difference could easily >>> be made up in minor >>> changes to my code. Thus here I consider there to be no >>> difference. >> >> Don't let the garbage collector fool you. >> See http://leves.web.elte.hu/collections/DictionaryBenchmarkResults.txt >> . >> The values in the table are microseconds/element without gc time. >> The benchmark code is here >> http://leves.web.elte.hu/collections/DictionaryBenchmark.st >> A similar benchmark's result for Set: >> >> Trunk: >> Size 1000 2000 5000 10000 20000 50000 100000 >> 200000 >> 500000 >> add: (included) 0.5 0.2 0.36 0.46 0.365 0.392 0.394 >> 0.406 0.4112 >> add: (not included) 1.5 1.6 1.38 1.35 1.365 1.25 >> 1.261 1.252 1.5192 >> ... > > I don't know what these stats are about. > I am merely quoting the stats you posted for the first version of > faster sets that you released. They indicated that for class Set > your method rehash was appx 15% faster than the version in > FasterSets and > your method add: was appx 1% faster than the version in FasterSets. > >> >>> b) Levente's version does not apply the FasterSets idea to >>> MethodDictionary. >>> I am not sure why he did not do this but it may have >>> something to do with the fact that >>> mistakes can easily corrupt your image. The version in >>> FasterSets works fine though >>> it took three tries for me to get it right (mostly because >>> of carelessness). >> > > >> It would be easy to modify MethodDictionary, but it has a different >> implementation, so most methods would have to be overridden and the >> performance benefits would be insignificant, because #become: is >> much (~80x) >> slower than the actual rehash for an average sized MethodDictionary. >> Btw, MethodDictionaries are rarely grown. > > >> >>> c) I left methods intersection and nastyAddNew: out of classes >>> Set and Dictionary for >>> the initial version of FasterSets to keep the number of >>> changes to a minimum. >>> At your request I added them to the current version. >>> These methods are not in >>> Levente's version. They are public methods that provide >>> performance improvements. >>> If desired they could easily be added to Levente's >>> version. >> >> #nastyAddNew: is not really useful IMO, if you want to be nasty, >> you can use >> "private" methods: >> aSet atNewIndex: (set scanForNil: anObject) put: anObject. >> It's even faster and if you do this, you probably know what you're >> doing. >> > > I don't know whether nastyAddNew: should be added to Pharo/Squeak > or not. > I'll leave that for others to decide. However, I consider > nastyAddNew: to be > preferable to what you propose. > >> I'm not really interrested in #intersecion:, but I found it >> controversal. >> What's the intersecion of a Set and an IdentitySet? Do you check >> identity or >> equality? >> > > The current code currently supports intersection of sets/dictionaries > but it is slower than > the version in FasterSets because the FasterSets version avoids > unnecessary compares. > If you believe that intersection for sets in the current code is > controversial and should be > changed or removed fine. FasterSets is not entering this debate; it > is merely providing > faster versions of intersection than what is already in the code. > >>> I recommend that >>> >>> 1) You use Levente's version. >> >> Feel free to grab it. >> >>> 2) Sort out the issue of no rehash method for Class >>> WeakKeyToCollectionDictionary. >> >> See above. >> >>> 3) Modify his code to use method scanForNilFrom: (calling it >>> scanForEmptySlotFrom:). >> >> See above. >> >>> 4) Decide if you want to add methods intersect: and >>> nastyAddNew:. >>> I can add these if you want. >> >> See my opinion above. >> >>> 5) Release a version of Pharo with these changes. >>> 6) In the following release of Pharo add the changes to >>> MethodDictionary to use The >>> FasterSets Idea. I sugggest doing this separately from >>> everything else just because it is a >>> bit hairy. I would not leave this change out because >>> MethodDictionary is too important >>> a class not to have these improvements. >>> >> >> See above. >> >>> You can post this on the Pharo newsgroup if you like but perhaps you >>> should get Levente's >>> opinion first. >> >> Go ahead, I'm already subscribed to the pharo list because I >> couldn't stop >> myself to respond to a false statement. >> >> Cheers, >> Levente >> > > Regards, > > Ralph Boland

Oct. 31, 2009

[Pharo-project] Fwd: Adding FasterSets to Pharo: update

by StÃ©phane Ducasse

Begin forwarded message: > From: Levente Uzonyi <leves(a)elte.hu> > Date: October 30, 2009 3:29:33 AM GMT+01:00 > To: Ralph Boland <rpboland(a)gmail.com> > Cc: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Subject: Re: Adding FasterSets to Pharo: update > > Hi! > > On Thu, 29 Oct 2009, Ralph Boland wrote: > >> In Levente's code class WeakKeyToCollectionDictionary->rehash >> seems to be >> missing. This appears to be a mistate to me but I will live it >> to Levente to explain >> it. The fix, if needed, is simple. > > Only Set and MethodDictionary implements #rehash in the trunk > version. #rehash sends #growTo: which sends #noCheckNoGrowFillFrom: > which is implemented by WeakKeyToCollectionDictionary. > >> b) Levente's version does not use method scanForNilFrom: (He >> would probably call >> the method scanForEmptySlotFrom:). >> I don't know why he didn't do this: it clearly cleaner. > > It's called #scanForEmptySlotFor:, because WeakSet has a flag for > empty slots, not nil. > >> b) The improvement in performance for method add: in >> Levente's version >> is insignificant (appx 1%); this difference could easily >> be made up in minor >> changes to my code. Thus here I consider there to be no >> difference. > > Don't let the garbage collector fool you. > See http://leves.web.elte.hu/collections/DictionaryBenchmarkResults.txt > . The values in the table are microseconds/element without gc time. > The benchmark code is here http://leves.web.elte.hu/collections/DictionaryBenchmark.st > A similar benchmark's result for Set: > > Trunk: > Size 1000 2000 5000 10000 20000 50000 100000 200000 500000 > add: (included) 0.5 0.2 0.36 0.46 0.365 0.392 0.394 0.406 0.4112 > add: (not included) 1.5 1.6 1.38 1.35 1.365 1.25 1.261 1.252 1.5192 > includes: (included) 0.3 0.5 0.42 0.41 0.395 0.432 0.457 0.4695 0.4442 > includes: (not included) 0.2 0.5 0.56 0.51 0.51 0.632 0.66 0.6525 > 0.5994 > like: (included) 0.5 0.4 0.4 0.36 0.345 0.37 0.393 0.4105 0.3854 > like: (not included) 0.4 0.45 0.52 0.44 0.445 0.566 0.593 0.5895 0.536 > rehash 0.5 0.4 0.32 0.33 0.33 0.338 0.342 0.326 0.3386 > remove:ifAbsent: (included) 0.7 0.95 1.02 0.99 1.015 1.228 1.238 > 1.2485 0.9282 > remove:ifAbsent: (not included) 0.4 0.5 0.58 0.54 0.575 0.686 0.699 > 0.6985 0.6586 > > Pharo: > Size 1000 2000 5000 10000 20000 50000 100000 200000 500000 > add: (included) 0.4 0.45 0.5 0.45 0.44 0.462 0.465 0.4705 0.499 > add: (not included) 2.0 2.0 1.72 1.67 1.715 1.57 1.582 1.57 2.0874 > includes: (included) 0.5 0.5 0.56 0.6 0.52 0.52 0.547 0.5335 0.5814 > includes: (not included) 0.7 0.85 0.8 1.03 0.865 0.804 0.804 0.8265 > 0.8734 > like: (included) 0.7 0.45 0.4 0.5 0.395 0.382 0.399 0.3935 0.4208 > like: (not included) 0.3 0.65 0.66 0.9 0.705 0.66 0.659 0.679 0.783 > rehash 0.9 0.6 0.64 0.69 0.63 0.604 0.615 0.6285 0.6964 > remove:ifAbsent: (included) 2.0 1.95 2.16 6.59 2.165 2.052 1.981 > 2.092 2.0544 > remove:ifAbsent: (not included) 0.9 0.85 0.92 1.05 0.9 0.84 0.878 > 0.869 1.0232 > > Pharo with Andres's hacks: > Size 1000 2000 5000 10000 20000 50000 100000 200000 500000 > add: (included) 0.5 0.5 0.46 0.49 0.475 0.466 0.458 0.4935 0.5306 > add: (not included) 1.7 2.35 2.26 2.02 2.15 2.12 2.298 2.021 2.0332 > includes: (included) 0.6 0.5 0.56 0.53 0.62 0.528 0.539 0.533 0.588 > includes: (not included) 0.8 0.8 0.74 0.77 0.745 0.7 0.694 0.706 > 0.7814 > like: (included) 0.1 0.2 0.36 0.4 0.485 0.386 0.39 0.382 0.4312 > like: (not included) 0.4 0.8 0.6 0.66 0.605 0.576 0.566 0.5835 0.6554 > rehash 0.6 0.55 0.62 0.58 0.575 0.586 0.599 0.5825 0.6044 > remove:ifAbsent: (included) 1.5 1.95 1.86 1.97 1.905 1.786 1.763 > 1.8005 1.9346 > remove:ifAbsent: (not included) 0.7 0.75 0.82 0.82 0.84 0.774 0.771 > 0.7755 0.8418 > > If you're interrested in the benchmark code, let me know. > >> b) Levente's version does not apply the FasterSets idea to >> MethodDictionary. >> I am not sure why he did not do this but it may have >> something to do with the fact that >> mistakes can easily corrupt your image. The version in >> FasterSets works fine though >> it took three tries for me to get it right (mostly because >> of carelessness). > > It would be easy to modify MethodDictionary, but it has a different > implementation, so most methods would have to be overridden and the > performance benefits would be insignificant, because #become: is > much (~80x) slower than the actual rehash for an average sized > MethodDictionary. > Btw, MethodDictionaries are rarely grown. > >> c) I left methods intersection and nastyAddNew: out of classes >> Set and Dictionary for >> the initial version of FasterSets to keep the number of >> changes to a minimum. >> At your request I added them to the current version. >> These methods are not in >> Levente's version. They are public methods that provide >> performance improvements. >> If desired they could easily be added to Levente's version. > > #nastyAddNew: is not really useful IMO, if you want to be nasty, you > can use "private" methods: > aSet atNewIndex: (set scanForNil: anObject) put: anObject. > It's even faster and if you do this, you probably know what you're > doing. > > I'm not really interrested in #intersecion:, but I found it > controversal. What's the intersecion of a Set and an IdentitySet? Do > you check identity or equality? > >> I recommend that >> >> 1) You use Levente's version. > > Feel free to grab it. > >> 2) Sort out the issue of no rehash method for Class >> WeakKeyToCollectionDictionary. > > See above. > >> 3) Modify his code to use method scanForNilFrom: (calling it >> scanForEmptySlotFrom:). > > See above. > >> 4) Decide if you want to add methods intersect: and >> nastyAddNew:. >> I can add these if you want. > > See my opinion above. > >> 5) Release a version of Pharo with these changes. >> 6) In the following release of Pharo add the changes to >> MethodDictionary to use The >> FasterSets Idea. I sugggest doing this separately from >> everything else just because it is a >> bit hairy. I would not leave this change out because >> MethodDictionary is too important >> a class not to have these improvements. >> > > See above. > >> You can post this on the Pharo newsgroup if you like but perhaps you >> should get Levente's >> opinion first. > > Go ahead, I'm already subscribed to the pharo list because I > couldn't stop myself to respond to a false statement. > > Cheers, > Levente

Oct. 31, 2009