June 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Why do we have SmallDictionary?

by ClÃ©ment Bera

Hi Max, Theoretically, for a small number of elements, usually somewhere between 3 and 30 depending on implementations, a linear search is faster than a hash search, especially in the Pharo dictionary hash search implementation. Efficient dictionary implementations are usually bucket-based. The dictionary holds a certain number of buckets, and based on the key hash, the bucket where the key value is present is determined. Small buckets are linear (arrays or linked list). Large buckets are typically balanced binary trees (red-black trees typically). Under a certain number of elements there is a single bucket, which means a linear search is performed, as for the SmallDictionary. When it grows the dictionary search becomes a combination between a hash search and a linear or tree search. Pharo dictionary search is first hash-based, then all the buckets are represented next to each other in the same arrays and a linear search is performed there, leading to many collisions and slower search time (especially when the element is not found), sometimes the code searches over multiple buckets because the dictionary is too full or there are too many near-collisions. The memory consumption is competitive with the advanced implementations though (precise measurements would need to be made). Method dictionaries are represented differently to optimize the look-up logic. If you want to improve things and have one dictionary implementation instead of two, implement or look for a bucket based dictionary and put it in the base image instead of Dictionary. This is quite some work since there are many APIs to port. You can look at the Pinnochio implementation, it's quite good but they've not implemented large buckets. On Fri, Jun 8, 2018 at 8:46 AM, Max Leske <maxleske(a)gmail.com> wrote: > Hi, > > I was messing around with SmallDictionary when I suddenly realised that I > can't find a single reason to use it over a normal Dictionary. While its > name and class comment imply that it is somehow an optimised Dictionary, I > don't see any measurement where that actually holds up. The following was > run in a Pharo 7 image on a recent VM (see below): > > | d | > d := SmallDictionary new. > d sizeInMemory. "24" > [100000 timesRepeat: [ > 1 to: 100 do: [ :i | d at:i put: i] ] ] timeToRun. "0:00:00:05.226" > > [100000 timesRepeat: [ > d at: 48 ifAbsent: [] ] ] timeToRun. "0:00:00:00.041" > > > > | d | > d := Dictionary new. > d sizeInMemory. "16" > [100000 timesRepeat: [ > 1 to: 100 do: [ :i | d at:i put: i] ] ] timeToRun. "0:00:00:00.385" > [100000 timesRepeat: [ > d at: 48 ifAbsent: [] ] ] timeToRun. "0:00:00:00.006" > > > As you can see, SmallDictionary is 8 bytes larger per instance and > significantly faster while reading and writing (I know that this isn't a > good benchmark but it suffices to make my point). > > > Is anyone aware of a reason for hanging on to SmallDictionary? I'm also > curious to know how SmallDictionary came to be. There must have been some > advantage over Dictionary at some point in the past. > > > Cheers, > Max > > > > > > Image version: Pharo 7.0 > Build information: Pharo-7.0+alpha.build.961.sha. > a69e72a97136bc3f93831584b6efa2b1703deb84 (32 Bit) > > VM version: CoInterpreter VMMaker.oscog- nice.2281 uuid: > 4beeaee7-567e-1a4b-b0fb-bd95ce302516 Nov 27 2017 > StackToRegisterMappingCogit VMMaker.oscog-nice.2283 uuid: > 2d20324d-a2ab-48d6-b0f6-9fc3d66899da Nov 27 2017 > VM: 201711262336 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > Date: Mon Nov 27 00:36:29 2017 +0100 $ Plugins: 201711262336 > https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > > OS: macOS 10.13.5 > Machine: MacBook Pro (13-inch, 2016, Four Thunderbolt 3 Ports) > > -- ClÃ©ment BÃ©ra https://clementbera.github.io/ https://clementbera.wordpress.com/

June 8, 2018

Re: [Pharo-dev] Why do we have SmallDictionary?

by Max Leske

On 8 Jun 2018, at 9:30, Max Leske wrote: > (Sorry, hit send accidentally). > > > On 8 Jun 2018, at 9:02, Marcus Denker wrote: > >>> On 8 Jun 2018, at 08:46, Max Leske <maxleske(a)gmail.com> wrote: >>> >>> Hi, >>> >>> I was messing around with SmallDictionary when I suddenly realised >>> that I can't find a single reason to use it over a normal >>> Dictionary. While its name and class comment imply that it is >>> somehow an optimised Dictionary, I don't see any measurement where >>> that actually holds up. The following was run in a Pharo 7 image on >>> a recent VM (see below): >>> >>> | d | >>> d := SmallDictionary new. >>> d sizeInMemory. "24" >>> [100000 timesRepeat: [ >>> 1 to: 100 do: [ :i | d at:i put: i] ] ] timeToRun. "0:00:00:05.226" >>> >>> [100000 timesRepeat: [ >>> d at: 48 ifAbsent: [] ] ] timeToRun. "0:00:00:00.041" >>> >>> >>> >>> | d | >>> d := Dictionary new. >>> d sizeInMemory. "16" >>> [100000 timesRepeat: [ >>> 1 to: 100 do: [ :i | d at:i put: i] ] ] timeToRun. "0:00:00:00.385" >>> [100000 timesRepeat: [ >>> d at: 48 ifAbsent: [] ] ] timeToRun. "0:00:00:00.006" >>> >>> >> can you try with <10 elements? > > The results are in! > Note that I had to increase the repetitions by a factor or 100. > > > | d | > d := SmallDictionary new. > [10000000 timesRepeat: [ > 1 to: 5 do: [ :i | d at:i put: i] ] ] timeToRun. "0:00:00:02.532" > > [10000000 timesRepeat: [ > d at: 4 ifAbsent: [] ] ] timeToRun. "0:00:00:00.686" > > > > | d | > d := Dictionary new. > [10000000 timesRepeat: [ > 1 to: 5 do: [ :i | d at:i put: i] ] ] timeToRun. "0:00:00:02.102" > > [10000000 timesRepeat: [ > d at: 4 ifAbsent: [] ] ] timeToRun. "0:00:00:00.567" > > > So SmallDictionary is indeed very fast for only few elements. Once the > SmallDictionary has to grow its performance decreases rapidly, or at > least the grow operation takes a long time. > Dictionary still outperforms SmallDictionary though, so I guess the > only reason left is space efficency. > > >>> >>> Is anyone aware of a reason for hanging on to SmallDictionary? I'm >>> also curious to know how SmallDictionary came to be. There must have >>> been some advantage over Dictionary at some point in the past. >>> >> It came from RBâ¦ the idea was that there are (in the Refactoring >> engine) a lot of very small dictionaries with <10 elements. >> The idea is that for such dictionaries, the overhead of hashing was >> higher than just linear search. >> >> I am sure I did a benchmark back then, but of course this could have >> changed in the meantime. >> >> It would be nice to redo the benchmark. That would be very nice, as I just realised, that the type of object used as key has an effect on the hashing time... There are a lot of variables here, unfortunately. Max >> >> For size: does #sizeInMemory take the internal data into account? e.g >> for Dictionary there is an Array that contains Associations, you need >> to count those, too. > > No, I didn't check for that initially. When I did, it became apparent > that the larger the dictionary the more space you save with > SmallDictionary. > >> >> In the end this is a hack anyway: if needed Dictionary could do >> things like this transparentlyâ¦ without the user having to decide. >> And the question is if this is not just a bad side effect of the >> particular implementation. > > Good point. Sounds like what Stefan Marr wrote in the paper where he > performed a field study of collection libraries ;) > > Max > >> >> Marcus

June 8, 2018

Re: [Pharo-dev] [ANN] Epicea, Ombu and Hiedra packages have new "official" repository

by Guillermo Polito

Hi, Can we define what we mean by "Light"? Are we talking about - memory consumption? - Dependencies? - Amount of code? - Complexity? - Size of API? Guille On Fri, Jun 8, 2018 at 2:31 AM, HernÃ¡n Morales <hernan.morales(a)gmail.com> wrote: > Hi Norbert, > > El 7 jun. 2018, a las 03:23, Norbert Hartl <norbert(a)hartl.name> escribiÃ³: > > > > Am 06.06.2018 um 22:00 schrieb HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com>: > > Hello Martin, > > 2018-06-05 15:49 GMT-03:00 Martin Dias <tinchodias(a)gmail.com>: > > On Tue, Jun 5, 2018 at 3:30 PM HernÃ¡n Morales Durand > <hernan.morales(a)gmail.com> wrote: > > What are Ombu and Hiedra? > > > Hello HernÃ¡n, this is how I described them: > > Ombu: > "Epicea has a small subproject, named Ombu, which provides simple > persistence. By default, Ombu uses STON to write the events when they > are announced in the system." > ------- from http://smalltalkhub.com/#!/~MartinDias/Epicea > > > Ok, so this could be used by any application to log events? Like a > lite version of Beacon logger? > > > Do you assume Beacon is not light? Doesnât really matter but a lot of > people seem to assume it is not. > > > I donât know, never used Beacon. However I know Log4s is not light and I > want to replace it in my projects for some simple logging mechanism. > > I think the are on two different axes. Beacon is more about distribution > of notifications in the system and Ombu seems to be a store only. So the > combination could be cool to have a consumer in beacon that writes to an > Ombu Store > > > Thank you for the tip, I will have a look because I am specially > interested in projects using Beacon. > > Cheers, > > HernÃ¡n > > > Norbert > > I am trying to get what would be the typical use case for a "common" app. > > Hiedra: > "It is a small Pharo project to visually connect items in a > history-like graph. It uses Athens, and provides support for Morphic > and Spec." > ------- from https://github.com/tinchodias/hiedra which is a repo that > I might close or should say in readme that it's not the official repo > > But not sure if I described correctly... in concrete, Hiedra is what's > used from Epicea Spec UI in a TableModel to draw the links between > epicea logs in the left panel. > > > Nice! > I am trying again to make re-use of your work if possible :) > I found a reference in EpLogNodeGraphModel. But could > HiRulerController be used off the Epicea case? > Maybe could you provide a stand-alone example? > > About the documentation use case: > > Class { > #name : #HiedraExampleModel, > #superclass : #ComposableModel, > #instVars : [ > 'treeModel rulerController' > ], > #category : #HiedraExample > } > > { #category : #initialization } > HiedraExampleModel >> initializePresenter [ > > super initializePresenter. > > rulerController := HiRulerController new. > > rulerController treeModel: treeModel. > treeModel whenRootsChanged: [ > rulerController updateFromTree ]. > > ] > > > How do you evaluate that code inside Pharo? > > Thank you, > > HernÃ¡n > > > > > > Cheers, MartÃn > > > Couldn't find any description in the link. > > Cheers, > > HernÃ¡n > > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

June 8, 2018

Re: [Pharo-dev] Why do we have SmallDictionary?

by Max Leske

(Sorry, hit send accidentally). On 8 Jun 2018, at 9:02, Marcus Denker wrote: >> On 8 Jun 2018, at 08:46, Max Leske <maxleske(a)gmail.com> wrote: >> >> Hi, >> >> I was messing around with SmallDictionary when I suddenly realised >> that I can't find a single reason to use it over a normal Dictionary. >> While its name and class comment imply that it is somehow an >> optimised Dictionary, I don't see any measurement where that actually >> holds up. The following was run in a Pharo 7 image on a recent VM >> (see below): >> >> | d | >> d := SmallDictionary new. >> d sizeInMemory. "24" >> [100000 timesRepeat: [ >> 1 to: 100 do: [ :i | d at:i put: i] ] ] timeToRun. "0:00:00:05.226" >> >> [100000 timesRepeat: [ >> d at: 48 ifAbsent: [] ] ] timeToRun. "0:00:00:00.041" >> >> >> >> | d | >> d := Dictionary new. >> d sizeInMemory. "16" >> [100000 timesRepeat: [ >> 1 to: 100 do: [ :i | d at:i put: i] ] ] timeToRun. "0:00:00:00.385" >> [100000 timesRepeat: [ >> d at: 48 ifAbsent: [] ] ] timeToRun. "0:00:00:00.006" >> >> > can you try with <10 elements? The results are in! Note that I had to increase the repetitions by a factor or 100. | d | d := SmallDictionary new. [10000000 timesRepeat: [ 1 to: 5 do: [ :i | d at:i put: i] ] ] timeToRun. "0:00:00:02.532" [10000000 timesRepeat: [ d at: 4 ifAbsent: [] ] ] timeToRun. "0:00:00:00.686" | d | d := Dictionary new. [10000000 timesRepeat: [ 1 to: 5 do: [ :i | d at:i put: i] ] ] timeToRun. "0:00:00:02.102" [10000000 timesRepeat: [ d at: 4 ifAbsent: [] ] ] timeToRun. "0:00:00:00.567" So SmallDictionary is indeed very fast for only few elements. Once the SmallDictionary has to grow its performance decreases rapidly, or at least the grow operation takes a long time. Dictionary still outperforms SmallDictionary though, so I guess the only reason left is space efficency. >> >> Is anyone aware of a reason for hanging on to SmallDictionary? I'm >> also curious to know how SmallDictionary came to be. There must have >> been some advantage over Dictionary at some point in the past. >> > It came from RBâ¦ the idea was that there are (in the Refactoring > engine) a lot of very small dictionaries with <10 elements. > The idea is that for such dictionaries, the overhead of hashing was > higher than just linear search. > > I am sure I did a benchmark back then, but of course this could have > changed in the meantime. > > It would be nice to redo the benchmark. > > For size: does #sizeInMemory take the internal data into account? e.g > for Dictionary there is an Array that contains Associations, you need > to count those, too. No, I didn't check for that initially. When I did, it became apparent that the larger the dictionary the more space you save with SmallDictionary. > > In the end this is a hack anyway: if needed Dictionary could do things > like this transparentlyâ¦ without the user having to decide. And the > question is if this is not just a bad side effect of the particular > implementation. Good point. Sounds like what Stefan Marr wrote in the paper where he performed a field study of collection libraries ;) Max > > Marcus

June 8, 2018

Re: [Pharo-dev] Why do we have SmallDictionary?

by Max Leske

On 8 Jun 2018, at 9:02, Marcus Denker wrote: >> On 8 Jun 2018, at 08:46, Max Leske <maxleske(a)gmail.com> wrote: >> >> Hi, >> >> I was messing around with SmallDictionary when I suddenly realised >> that I can't find a single reason to use it over a normal Dictionary. >> While its name and class comment imply that it is somehow an >> optimised Dictionary, I don't see any measurement where that actually >> holds up. The following was run in a Pharo 7 image on a recent VM >> (see below): >> >> | d | >> d := SmallDictionary new. >> d sizeInMemory. "24" >> [100000 timesRepeat: [ >> 1 to: 100 do: [ :i | d at:i put: i] ] ] timeToRun. "0:00:00:05.226" >> >> [100000 timesRepeat: [ >> d at: 48 ifAbsent: [] ] ] timeToRun. "0:00:00:00.041" >> >> >> >> | d | >> d := Dictionary new. >> d sizeInMemory. "16" >> [100000 timesRepeat: [ >> 1 to: 100 do: [ :i | d at:i put: i] ] ] timeToRun. "0:00:00:00.385" >> [100000 timesRepeat: [ >> d at: 48 ifAbsent: [] ] ] timeToRun. "0:00:00:00.006" >> >> > can you try with <10 elements? The results are in! Note that I had to increase the repetitions by a factor or 100. | d | d := SmallDictionary new. [10000000 timesRepeat: [ 1 to: 5 do: [ :i | d at:i put: i] ] ] timeToRun. "0:00:00:02.532" [10000000 timesRepeat: [ d at: 4 ifAbsent: [] ] ] timeToRun. "0:00:00:00.686" | d | d := Dictionary new. [10000000 timesRepeat: [ 1 to: 5 do: [ :i | d at:i put: i] ] ] timeToRun. "0:00:00:02.102" [10000000 timesRepeat: [ d at: 4 ifAbsent: [] ] ] timeToRun. "0:00:00:00.567" >> >> Is anyone aware of a reason for hanging on to SmallDictionary? I'm >> also curious to know how SmallDictionary came to be. There must have >> been some advantage over Dictionary at some point in the past. >> > It came from RBâ¦ the idea was that there are (in the Refactoring > engine) a lot of very small dictionaries with <10 elements. > The idea is that for such dictionaries, the overhead of hashing was > higher than just linear search. > > I am sure I did a benchmark back then, but of course this could have > changed in the meantime. > > It would be nice to redo the benchmark. > > For size: does #sizeInMemory take the internal data into account? e.g > for Dictionary there is an Array that contains Associations, you need > to count those, too. > > In the end this is a hack anyway: if needed Dictionary could do things > like this transparentlyâ¦ without the user having to decide. And the > question is if this is not just a bad side effect of the particular > implementation. > > Marcus

June 8, 2018

Re: [Pharo-dev] Why do we have SmallDictionary?

by Marcus Denker

> On 8 Jun 2018, at 08:46, Max Leske <maxleske(a)gmail.com> wrote: > > Hi, > > I was messing around with SmallDictionary when I suddenly realised that I can't find a single reason to use it over a normal Dictionary. While its name and class comment imply that it is somehow an optimised Dictionary, I don't see any measurement where that actually holds up. The following was run in a Pharo 7 image on a recent VM (see below): > > | d | > d := SmallDictionary new. > d sizeInMemory. "24" > [100000 timesRepeat: [ > 1 to: 100 do: [ :i | d at:i put: i] ] ] timeToRun. "0:00:00:05.226" > > [100000 timesRepeat: [ > d at: 48 ifAbsent: [] ] ] timeToRun. "0:00:00:00.041" > > > > | d | > d := Dictionary new. > d sizeInMemory. "16" > [100000 timesRepeat: [ > 1 to: 100 do: [ :i | d at:i put: i] ] ] timeToRun. "0:00:00:00.385" > [100000 timesRepeat: [ > d at: 48 ifAbsent: [] ] ] timeToRun. "0:00:00:00.006" > > can you try with <10 elements? > > Is anyone aware of a reason for hanging on to SmallDictionary? I'm also curious to know how SmallDictionary came to be. There must have been some advantage over Dictionary at some point in the past. > It came from RBâ¦ the idea was that there are (in the Refactoring engine) a lot of very small dictionaries with <10 elements. The idea is that for such dictionaries, the overhead of hashing was higher than just linear search. I am sure I did a benchmark back then, but of course this could have changed in the meantime. It would be nice to redo the benchmark. For size: does #sizeInMemory take the internal data into account? e.g for Dictionary there is an Array that contains Associations, you need to count those, too. In the end this is a hack anyway: if needed Dictionary could do things like this transparentlyâ¦ without the user having to decide. And the question is if this is not just a bad side effect of the particular implementation. Marcus

June 8, 2018

Re: [Pharo-dev] Why do we have SmallDictionary?

by Max Leske

Well, I can answer my own question: SmallDictionary is a lot more space efficient. I think the class comment should clarify the use case for SmallDictionary and mention the performance trade off. Max On 8 Jun 2018, at 8:46, Max Leske wrote: > Hi, > > I was messing around with SmallDictionary when I suddenly realised > that I can't find a single reason to use it over a normal Dictionary. > While its name and class comment imply that it is somehow an optimised > Dictionary, I don't see any measurement where that actually holds up. > The following was run in a Pharo 7 image on a recent VM (see below): > > | d | > d := SmallDictionary new. > d sizeInMemory. "24" > [100000 timesRepeat: [ > 1 to: 100 do: [ :i | d at:i put: i] ] ] timeToRun. "0:00:00:05.226" > > [100000 timesRepeat: [ > d at: 48 ifAbsent: [] ] ] timeToRun. "0:00:00:00.041" > > > > | d | > d := Dictionary new. > d sizeInMemory. "16" > [100000 timesRepeat: [ > 1 to: 100 do: [ :i | d at:i put: i] ] ] timeToRun. "0:00:00:00.385" > [100000 timesRepeat: [ > d at: 48 ifAbsent: [] ] ] timeToRun. "0:00:00:00.006" > > > As you can see, SmallDictionary is 8 bytes larger per instance and > significantly faster while reading and writing (I know that this isn't > a good benchmark but it suffices to make my point). > > > Is anyone aware of a reason for hanging on to SmallDictionary? I'm > also curious to know how SmallDictionary came to be. There must have > been some advantage over Dictionary at some point in the past. > > > Cheers, > Max > > > > > > Image version: Pharo 7.0 > Build information: > Pharo-7.0+alpha.build.961.sha.a69e72a97136bc3f93831584b6efa2b1703deb84 > (32 Bit) > > VM version: CoInterpreter VMMaker.oscog- nice.2281 uuid: > 4beeaee7-567e-1a4b-b0fb-bd95ce302516 Nov 27 2017 > StackToRegisterMappingCogit VMMaker.oscog-nice.2283 uuid: > 2d20324d-a2ab-48d6-b0f6-9fc3d66899da Nov 27 2017 > VM: 201711262336 https://github.com/OpenSmalltalk/opensmalltalk-vm.git > $ Date: Mon Nov 27 00:36:29 2017 +0100 $ Plugins: 201711262336 > https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > > OS: macOS 10.13.5 > Machine: MacBook Pro (13-inch, 2016, Four Thunderbolt 3 Ports)

June 8, 2018

Re: [Pharo-dev] Why do we have SmallDictionary?

by Esteban Lorenzano

Hi, it was supposed to be optimised for small sizes so I guessed it was about your choice of 100000 elements, but a fast benchmark with small numbers didnât offered better results. So question is appropriate. Why we have it? Or better: why SmallDictionary is not faster? Even better: is this test good? :) cheers, Esteban > On 8 Jun 2018, at 08:46, Max Leske <maxleske(a)gmail.com> wrote: > > Hi, > > I was messing around with SmallDictionary when I suddenly realised that I can't find a single reason to use it over a normal Dictionary. While its name and class comment imply that it is somehow an optimised Dictionary, I don't see any measurement where that actually holds up. The following was run in a Pharo 7 image on a recent VM (see below): > > | d | > d := SmallDictionary new. > d sizeInMemory. "24" > [100000 timesRepeat: [ > 1 to: 100 do: [ :i | d at:i put: i] ] ] timeToRun. "0:00:00:05.226" > > [100000 timesRepeat: [ > d at: 48 ifAbsent: [] ] ] timeToRun. "0:00:00:00.041" > > > > | d | > d := Dictionary new. > d sizeInMemory. "16" > [100000 timesRepeat: [ > 1 to: 100 do: [ :i | d at:i put: i] ] ] timeToRun. "0:00:00:00.385" > [100000 timesRepeat: [ > d at: 48 ifAbsent: [] ] ] timeToRun. "0:00:00:00.006" > > > As you can see, SmallDictionary is 8 bytes larger per instance and significantly faster while reading and writing (I know that this isn't a good benchmark but it suffices to make my point). > > > Is anyone aware of a reason for hanging on to SmallDictionary? I'm also curious to know how SmallDictionary came to be. There must have been some advantage over Dictionary at some point in the past. > > > Cheers, > Max > > > > > > Image version: Pharo 7.0 > Build information: Pharo-7.0+alpha.build.961.sha.a69e72a97136bc3f93831584b6efa2b1703deb84 (32 Bit) > > VM version: CoInterpreter VMMaker.oscog- nice.2281 uuid: 4beeaee7-567e-1a4b-b0fb-bd95ce302516 Nov 27 2017 > StackToRegisterMappingCogit VMMaker.oscog-nice.2283 uuid: 2d20324d-a2ab-48d6-b0f6-9fc3d66899da Nov 27 2017 > VM: 201711262336 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Mon Nov 27 00:36:29 2017 +0100 $ Plugins: 201711262336 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > > OS: macOS 10.13.5 > Machine: MacBook Pro (13-inch, 2016, Four Thunderbolt 3 Ports) >

June 8, 2018

Why do we have SmallDictionary?

by Max Leske

Hi, I was messing around with SmallDictionary when I suddenly realised that I can't find a single reason to use it over a normal Dictionary. While its name and class comment imply that it is somehow an optimised Dictionary, I don't see any measurement where that actually holds up. The following was run in a Pharo 7 image on a recent VM (see below): | d | d := SmallDictionary new. d sizeInMemory. "24" [100000 timesRepeat: [ 1 to: 100 do: [ :i | d at:i put: i] ] ] timeToRun. "0:00:00:05.226" [100000 timesRepeat: [ d at: 48 ifAbsent: [] ] ] timeToRun. "0:00:00:00.041" | d | d := Dictionary new. d sizeInMemory. "16" [100000 timesRepeat: [ 1 to: 100 do: [ :i | d at:i put: i] ] ] timeToRun. "0:00:00:00.385" [100000 timesRepeat: [ d at: 48 ifAbsent: [] ] ] timeToRun. "0:00:00:00.006" As you can see, SmallDictionary is 8 bytes larger per instance and significantly faster while reading and writing (I know that this isn't a good benchmark but it suffices to make my point). Is anyone aware of a reason for hanging on to SmallDictionary? I'm also curious to know how SmallDictionary came to be. There must have been some advantage over Dictionary at some point in the past. Cheers, Max Image version: Pharo 7.0 Build information: Pharo-7.0+alpha.build.961.sha.a69e72a97136bc3f93831584b6efa2b1703deb84 (32 Bit) VM version: CoInterpreter VMMaker.oscog- nice.2281 uuid: 4beeaee7-567e-1a4b-b0fb-bd95ce302516 Nov 27 2017 StackToRegisterMappingCogit VMMaker.oscog-nice.2283 uuid: 2d20324d-a2ab-48d6-b0f6-9fc3d66899da Nov 27 2017 VM: 201711262336 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Mon Nov 27 00:36:29 2017 +0100 $ Plugins: 201711262336 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ OS: macOS 10.13.5 Machine: MacBook Pro (13-inch, 2016, Four Thunderbolt 3 Ports)

June 8, 2018

Re: [Pharo-dev] [ANN] Epicea, Ombu and Hiedra packages have new "official" repository

by HernÃ¡n Morales

Hi Norbert, > El 7 jun. 2018, a las 03:23, Norbert Hartl <norbert(a)hartl.name> escribiÃ³: > > > >> Am 06.06.2018 um 22:00 schrieb HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: >> >> Hello Martin, >> >> 2018-06-05 15:49 GMT-03:00 Martin Dias <tinchodias(a)gmail.com>: >>> On Tue, Jun 5, 2018 at 3:30 PM HernÃ¡n Morales Durand >>> <hernan.morales(a)gmail.com> wrote: >>>> What are Ombu and Hiedra? >>> >>> Hello HernÃ¡n, this is how I described them: >>> >>> Ombu: >>> "Epicea has a small subproject, named Ombu, which provides simple >>> persistence. By default, Ombu uses STON to write the events when they >>> are announced in the system." >>> ------- from http://smalltalkhub.com/#!/~MartinDias/Epicea >>> >> >> Ok, so this could be used by any application to log events? Like a >> lite version of Beacon logger? > > Do you assume Beacon is not light? Doesnât really matter but a lot of people seem to assume it is not. > I donât know, never used Beacon. However I know Log4s is not light and I want to replace it in my projects for some simple logging mechanism. > I think the are on two different axes. Beacon is more about distribution of notifications in the system and Ombu seems to be a store only. So the combination could be cool to have a consumer in beacon that writes to an Ombu Store > Thank you for the tip, I will have a look because I am specially interested in projects using Beacon. Cheers, HernÃ¡n > Norbert >> I am trying to get what would be the typical use case for a "common" app. >> >>> Hiedra: >>> "It is a small Pharo project to visually connect items in a >>> history-like graph. It uses Athens, and provides support for Morphic >>> and Spec." >>> ------- from https://github.com/tinchodias/hiedra which is a repo that >>> I might close or should say in readme that it's not the official repo >>> >>> But not sure if I described correctly... in concrete, Hiedra is what's >>> used from Epicea Spec UI in a TableModel to draw the links between >>> epicea logs in the left panel. >> >> Nice! >> I am trying again to make re-use of your work if possible :) >> I found a reference in EpLogNodeGraphModel. But could >> HiRulerController be used off the Epicea case? >> Maybe could you provide a stand-alone example? >> >> About the documentation use case: >> >> Class { >> #name : #HiedraExampleModel, >> #superclass : #ComposableModel, >> #instVars : [ >> 'treeModel rulerController' >> ], >> #category : #HiedraExample >> } >> >> { #category : #initialization } >> HiedraExampleModel >> initializePresenter [ >> >> super initializePresenter. >> >> rulerController := HiRulerController new. >> >> rulerController treeModel: treeModel. >> treeModel whenRootsChanged: [ >> rulerController updateFromTree ]. >> >> ] >> >> >> How do you evaluate that code inside Pharo? >> >> Thank you, >> >> HernÃ¡n >> >> >> >> >>> >>> Cheers, MartÃn >>> >>>> >>>> Couldn't find any description in the link. >>>> >>>> Cheers, >>>> >>>> HernÃ¡n

June 8, 2018