January 2015 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] 814baf: 40448

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 814baf496e8f2042c42b6622b637c2aa214ad96b https://github.com/pharo-project/pharo-core/commit/814baf496e8f2042c42b6622… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-01-16 (Fri, 16 Jan 2015) Changed paths: M DebuggerModel.package/DebugSession.class/instance/debugging actions/stepInto_.st M DebuggerModel.package/DebugSession.class/instance/debugging actions/stepOver_.st M DebuggerModel.package/DebugSession.class/instance/debugging actions/stepThrough_.st M DebuggerModel.package/DebugSession.class/instance/evaluating/rewindContextToMethod_fromContext_.st M DebuggerModel.package/DebugSession.class/instance/evaluating/unwindAndRestartToContext_.st A DebuggerModel.package/DebugSession.class/instance/private/stepToFirstInterestingBytecodeIn_.st A Kernel.package/PackageManifest.class/README.md A Kernel.package/PackageManifest.class/class/testing/isManifest.st A Kernel.package/PackageManifest.class/definition.st A Kernel.package/PackageManifest.class/instance/code-critics/rejectClasses.st A Kernel.package/PackageManifest.class/instance/code-critics/rejectRules.st A Kernel.package/PackageManifest.class/instance/comparing/=.st A Kernel.package/PackageManifest.class/instance/comparing/hash.st R Manifest-Core.package/PackageManifest.class/README.md R Manifest-Core.package/PackageManifest.class/class/testing/isManifest.st R Manifest-Core.package/PackageManifest.class/definition.st R Manifest-Core.package/PackageManifest.class/instance/code-critics/rejectClasses.st R Manifest-Core.package/PackageManifest.class/instance/code-critics/rejectRules.st R Manifest-Core.package/PackageManifest.class/instance/comparing/=.st R Manifest-Core.package/PackageManifest.class/instance/comparing/hash.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script448.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40448.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Traits.package/ClassTrait.class/instance/initialize-release/slots_.st A Traits.package/TApplyingOnClassSide.class/instance/initialize-release/slots_.st Log Message: ----------- 40448 14622 PackageManifest can not be in package Manifest-Core... https://pharo.fogbugz.com/f/cases/14622 14738 DebugSession assumes sending #stepToSendOrReturn is always needed https://pharo.fogbugz.com/f/cases/14738 14740 Faiing test: testMetaclassAndTraitClassRespectsPolymorphismRules https://pharo.fogbugz.com/f/cases/14740 http://files.pharo.org/image/40/40448.zip

Jan. 15, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40448 Home: https://github.com/pharo-project/pharo-core

Jan. 15, 2015

Re: [Pharo-dev] Finish one thing today

by Sebastian Sastre

Silly is to be tricked by the normal bias of your brain. The point of the text is that you have two gazillion unfinished things and what matters is what you finished instead. Here is a big +1 for that text > On Jan 15, 2015, at 4:36 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > > personally I dont see the point and it looks silly. Sometimes things take more time, sometimes releasing frequently is not a good idea because it comes with its own costs and delays. Coding like anything else in life is about critical thinking. Its about sitting down and deciding whats the best course for your project and if the course fails you change it. So I will have to be the only one here to thumb down this. > > On Wed, Jan 14, 2015 at 6:10 PM, Pablo R. Digonzelli <pdigonzelli(a)gmail.com <mailto:pdigonzelli@gmail.com>> wrote: > +1 > > Ing. Pablo Digonzelli > Software Solutions > IP-Solutiones SRL > Metrotec SRL > 25 de Mayo 521 > San Miguel de TucumÃ¡n > Email: pdigonzelli(a)softsargentina.com <mailto:pdigonzelli@softsargentina.com> > pdigonzelli(a)gmail.com <mailto:pdigonzelli@gmail.com> > Cel: 5493815982714 > > ----- Mensaje original ----- > De: "Lorenzo Schiavina" <lorenzo(a)edor.it <mailto:lorenzo@edor.it>> > Para: "Pharo Development List" <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org>> > Enviados: MiÃ©rcoles, 14 de Enero 2015 13:09:53 > Asunto: [Pharo-dev] R: Finish one thing today > > +1 > > Lorenzo > > -----Messaggio originale----- > Da: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org <mailto:pharo-dev-bounces@lists.pharo.org>] Per conto di Sven > Van Caekenberghe > Inviato: mercoledÃ¬ 14 gennaio 2015 16:16 > A: Pharo Development List > Oggetto: Re: [Pharo-dev] Finish one thing today > > > > On 14 Jan 2015, at 15:12, Pablo Estefo <pestefo(a)gmail.com <mailto:pestefo@gmail.com>> wrote: > > > > Wow... powerful message > > +1 > > > On 14 January 2015 at 10:32, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: > > This is nice: > > > > http://finishonethingtoday.com <http://finishonethingtoday.com/> > > > > > > Marcus > > > > > > > >

Jan. 15, 2015

Roassal and super large screen

by Alexandre Bergel

Dear all, We have reached a milestone today. We have been able to make Roassal display on a super large screen gently provided by INRIA Chile. If there would be a contest on displaying Roassal-made visualizations on the largest (and most expensive) super-screen ever, then we will be on a good run. >From the technical point of view, we export SVG and use a cluster-friendly SVG renderer. This expands the range of what can be achieved. Cheers, The Object Profile Team -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 15, 2015

Re: [Pharo-dev] Hosting the Pharo VM on MirageOS

by Alain Rastoul

Le 15/01/2015 20:58, Joerg Beekmann, DeepCove Labs a Ã©crit : > > >>> >>>> -----Original Message----- >>>> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf >>>> Of Alain Rastoul >>>> Sent: Wednesday, January 14, 2015 10:39 PM >>>> To: pharo-dev(a)lists.pharo.org >>>> Subject: Re: [Pharo-dev] Hosting the Pharo VM on MirageOS >>>> >>>> Le 15/01/2015 03:08, Joerg Beekmann, DeepCove Labs a Ã©crit : >>>>> >>>>> I was not planning specializing the VM for the image. But rather >>>>> link in a VM with everything needed to run a range of images. The >>>>> dependencies are handled by creating an OCAML module that expresses >>>> these and the VM code then lives in the module. The OCAML dependence >>>> analyser (a sat solver) then ensures those are satisfied. >>>>> >>>> But if you don't have a specialized smalltalk vm and image, you will >>>> have to embed full system dependencies, in order to build a full >>>> working smalltalk system (having most part not working could be a >>>> very bad thing), and then you loose the unikernel approach benefits >>>> (very lean dedicated system, small attack surface etc.). >>> My implicit assumption was that these VM would be designed for running >> headless web-services on smaller EC2 instances. And perhaps naively was >> thinking that the number of system dependencies would be quite low: >>> >>> - memory >>> - CPU >>> - networking stack >>> - http/https >>> >>> - no file system but access to block storage (or perhaps even link >>> image in so no storage at all) >>> - mirage is single threaded with green threads so no >>> multithreading/processing >> >> Honestly, the VM is not that large. There are not many variation points on that >> level. >> Where you want specialization is the *image*. > > Thanks Marcus - good to know > >> >> Marcus > > > Yes, the vm is not so big, and specialization has to be done in the image. But there is a key point to mention about openmirage : if it started as unix (or linux, don't know), it is not linux at all as I understand it See chapter 3 http://queue.acm.org/detail.cfm?id=2566628 " ... The last compilation strategy drops the dependency on Unix entirely and recompiles the MirNet module to link directly to a Xen network driver, which in turn pulls in all the dependencies it needs to boot on Xen. This progressive recompilation is key to the usability of MirageOS, ... etc" The compilation process produce a single compiled unit that includes your application linked with the needed libraries, ie: the kernel+application, there is no linux kernel and no processes at all. Even driver's code is linked to you application. It can be booted in a Xen guest vm like PharoNOS, Linux tiny core or others linux but ... I see a completely different animal is here :) if I'm wrong, please correct me NB: Is this thread about pharo devel ? or should it be moved to pharo-users ? -- Regards, Alain

Jan. 15, 2015

Re: [Pharo-dev] Implementing lazy loading for expandable collections (part 2)

by Alexandre Bergel

Hi Jimmie, You are having a micro-benchmark here. It is dangerous to judge the performance of a language with a simple benchmark :-) With AstroCloud [*] we handle very large images with consume a sizable memory portion. We indeed had to carefully think about some crucial parts to make AstroCloud fast. However, it was not complex at all to do. So, Pharo is not as fast as other languages. However, I believe it does not matter that much in many situations. And when performance really matters, then you can always write portion of the code (actually a couple of short methods) in C. Cheers, Alexandre [*] http://astrocloudy.wordpress.com > On Jan 15, 2015, at 3:46 PM, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: > > I do not understand what is happening here. > > oc := OrderedCollection new: 10000. > oc size. "0" > > a := Array new: 10000. > a size. "10000" > > So it seems that the #new: isn't creating an OrderedCollection of the size we pass in. > > I discovered this when I attempted to do the identical test but with an Array instead of an OrderedCollection. Since the Array doesn't #add: I had to change the code to #at:put:. > > When I noticed all of the OC code did #add: even if supposedly setting its size to 10000(0). I tried to use #at:put: in the OrderedCollection but it failed because their was no index 1, because the size was still 0. > > I naively would have thought that OrderedCollection new: 10000 would return an OrderedCollection of 10000 empty/nil elements and that I could #at:put: into any of those 10000 slots and #add if I needed to go beyond those 10000. > > Tests done on a laptop with Windows 7, Pharo 4 latest image, latest stable vm, 3rd gen i7 processor, 12gb ram. > > I did all of the tests in Pharo 4 and added my Array test. > 0:00:00:04.37 > 0:00:00:03.183 > 0:00:00:03.674 > 0:00:00:03.753 > 0:00:00:01.647 and with an Array instead of OrderedCollection > > So we can see if we know the max size and create the collection with that size it should improve performance. > > I also do not understand why Pharo is so slow on this? > > With the preallocated Array above it took 1.647 seconds. > > Python 3.4.2, 0.003 seconds with 10,000 ints, and 0.17 with 1,000,000 ints. > Julia 3.5, 0.005 seconds with 1,000,000 Int64. > > Now I don't expect Pharo to keep up with Julia. But we aren't even in the neighborhood with Python. > > I really would like to use Pharo. It really is my favorite language and environment. But these performance numbers give me pause. > > Jimmie > > > On 1/14/2015 3:53 AM, Max Leske wrote: >> Hi Alex >> >> I thought the following little experiment might interest you. >> >> I was trying to find out (as per your suggestion) how big the difference would be between: >> - setting the array in OrderedCollection to nil and initializing it to size 10 on first access >> - initializing the array in OrderedCollection to size 0. >> >> Expectation: #grow will take time, ergo, using an empty array should be slower than using >> a preallocated array. >> >> Experiment (Pharo 1.3 on SqueakVM): >> >> >> [ 10000 timesRepeat: [ | c | c := OrderedCollection new: 100000. >> 1 to: 10000 do: [ :i | c add: i ] ] ] timeToRun 17566 >> >> [ 10000 timesRepeat: [ | c | c := OrderedCollection new: 10000. >> 1 to: 10000 do: [ :i | c add: i ] ] ] timeToRun 19717 >> >> [ 10000 timesRepeat: [ | c | c := OrderedCollection new: 0. >> 1 to: 10000 do: [ :i | c add: i ] ] ] timeToRun 17598 >> >> >> >> [ 10000 timesRepeat: [ | c | c := OrderedCollection new: 1000. >> 1 to: 10000 do: [ :i | c add: i ] ] ] timeToRun 18084 >> >> >> >> Result: growing a collection is always faster (or at least nearly equally fast)! >> >> Explanation: What makes preinitialized collections so slow is the fact the the firstIndex variable will be set to >> the first third of the array (3333 in this case). When the last position in the array is reached, all elements >> are copied to the beginning of the array (2n operations). This copy operation is really slow (which can be seen >> from the first example with an oversized collection that does not require copying because the last position >> of the array is never reached). >> >> >> Experiment (Pharo 4 on PharoVM): >> (Iâm using bigger numbers here to compensate for the faster VM :) ) >> >> >> [ 10000 timesRepeat: [ | c | c := OrderedCollection new: 1000000. >> 1 to: 100000 do: [ :i | c add: i ] ] ] timeToRun "0:00:01:09.225" >> >> [ 10000 timesRepeat: [ | c | c := OrderedCollection new: 100000. >> 1 to: 100000 do: [ :i | c add: i ] ] ] timeToRun "0:00:00:37.653" >> >> [ 10000 timesRepeat: [ | c | c := OrderedCollection new: 0. >> 1 to: 100000 do: [ :i | c add: i ] ] ] timeToRun "0:00:00:40.152" >> >> >> >> [ 10000 timesRepeat: [ | c | c := OrderedCollection new: 10000. >> 1 to: 100000 do: [ :i | c add: i ] ] ] timeToRun "0:00:00:42.121â >> >> >> >> Result: growing a collection is easily fast enough, although minute performance gains are possible with preinitialized collections. >> >> Explanation: #makeRoomAtLast has been improved. Also: firstIndex is now set to the beginning of the array, preventing the copy >> operation that made the former measurements so slow. >> The run with the oversized collection is only so slow because it apparently takes a lot of time to assign the large array (?). >> >> >> Consequence of my little experiment: My initial implementation of the idea in you paper set the array in OrderedCollection to nil >> under the assumption that grow operations are very costly. That choice leads to many changes in methods of OrderedCollection >> where it is necessary to check if the array has been initialized yet. This introduces overhead and makes the code more error prone. >> I see now that it makes much more sense to use an empty array, the performance lost by growing ist neglectable. >> >> It is also interesting to note that there almost never seems to be a good reason to initialize an OrderedCollection with a large array. >> >> >> Cheers, >> Max > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 15, 2015

Re: [Pharo-dev] Hosting the Pharo VM on MirageOS

by Joerg Beekmann, DeepCove Labs

> > > >> -----Original Message----- > >> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf > >> Of Alain Rastoul > >> Sent: Wednesday, January 14, 2015 10:39 PM > >> To: pharo-dev(a)lists.pharo.org > >> Subject: Re: [Pharo-dev] Hosting the Pharo VM on MirageOS > >> > >> Le 15/01/2015 03:08, Joerg Beekmann, DeepCove Labs a Ã©crit : > >>> > >>> I was not planning specializing the VM for the image. But rather > >>> link in a VM with everything needed to run a range of images. The > >>> dependencies are handled by creating an OCAML module that expresses > >> these and the VM code then lives in the module. The OCAML dependence > >> analyser (a sat solver) then ensures those are satisfied. > >>> > >> But if you don't have a specialized smalltalk vm and image, you will > >> have to embed full system dependencies, in order to build a full > >> working smalltalk system (having most part not working could be a > >> very bad thing), and then you loose the unikernel approach benefits > >> (very lean dedicated system, small attack surface etc.). > > My implicit assumption was that these VM would be designed for running > headless web-services on smaller EC2 instances. And perhaps naively was > thinking that the number of system dependencies would be quite low: > > > > - memory > > - CPU > > - networking stack > > - http/https > > > > - no file system but access to block storage (or perhaps even link > > image in so no storage at all) > > - mirage is single threaded with green threads so no > > multithreading/processing > > Honestly, the VM is not that large. There are not many variation points on that > level. > Where you want specialization is the *image*. Thanks Marcus - good to know > > Marcus

Jan. 15, 2015

Re: [Pharo-dev] Implementing lazy loading for expandable collections (part 2)

by Sven Van Caekenberghe

Jimmy, > On 15 Jan 2015, at 19:46, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: > > I do not understand what is happening here. > > oc := OrderedCollection new: 10000. > oc size. "0" > > a := Array new: 10000. > a size. "10000" > > So it seems that the #new: isn't creating an OrderedCollection of the size we pass in. > > I discovered this when I attempted to do the identical test but with an Array instead of an OrderedCollection. Since the Array doesn't #add: I had to change the code to #at:put:. This is all normal and by design. OrderedCollection is a growable collection, designed so you can add elements at either end. The thread's discussion is about growing strategies. Consider, (OrderedCollection new: 100) capacity = 100 it means it has preallocated room for a 100 elements, but the way it is managed is tricky, as people discovered. > When I noticed all of the OC code did #add: even if supposedly setting its size to 10000(0). I tried to use #at:put: in the OrderedCollection but it failed because their was no index 1, because the size was still 0. > > I naively would have thought that OrderedCollection new: 10000 would return an OrderedCollection of 10000 empty/nil elements and that I could #at:put: into any of those 10000 slots and #add if I needed to go beyond those 10000. > > Tests done on a laptop with Windows 7, Pharo 4 latest image, latest stable vm, 3rd gen i7 processor, 12gb ram. > > I did all of the tests in Pharo 4 and added my Array test. > 0:00:00:04.37 > 0:00:00:03.183 > 0:00:00:03.674 > 0:00:00:03.753 > 0:00:00:01.647 and with an Array instead of OrderedCollection > > So we can see if we know the max size and create the collection with that size it should improve performance. > > I also do not understand why Pharo is so slow on this? > > With the preallocated Array above it took 1.647 seconds. > > Python 3.4.2, 0.003 seconds with 10,000 ints, and 0.17 with 1,000,000 ints. > Julia 3.5, 0.005 seconds with 1,000,000 Int64. > > Now I don't expect Pharo to keep up with Julia. But we aren't even in the neighborhood with Python. > > I really would like to use Pharo. It really is my favorite language and environment. But these performance numbers give me pause. There are differently sized loops in this thread, what exactly did you try ? What is the Python code that you ran ? Benchmarking is always dangerous, you must make absolutely clear what you are running and comparing. Sven > Jimmie > > > On 1/14/2015 3:53 AM, Max Leske wrote: >> Hi Alex >> >> I thought the following little experiment might interest you. >> >> I was trying to find out (as per your suggestion) how big the difference would be between: >> - setting the array in OrderedCollection to nil and initializing it to size 10 on first access >> - initializing the array in OrderedCollection to size 0. >> >> Expectation: #grow will take time, ergo, using an empty array should be slower than using >> a preallocated array. >> >> Experiment (Pharo 1.3 on SqueakVM): >> >> >> [ 10000 timesRepeat: [ | c | c := OrderedCollection new: 100000. >> 1 to: 10000 do: [ :i | c add: i ] ] ] timeToRun 17566 >> >> [ 10000 timesRepeat: [ | c | c := OrderedCollection new: 10000. >> 1 to: 10000 do: [ :i | c add: i ] ] ] timeToRun 19717 >> >> [ 10000 timesRepeat: [ | c | c := OrderedCollection new: 0. >> 1 to: 10000 do: [ :i | c add: i ] ] ] timeToRun 17598 >> >> >> >> [ 10000 timesRepeat: [ | c | c := OrderedCollection new: 1000. >> 1 to: 10000 do: [ :i | c add: i ] ] ] timeToRun 18084 >> >> >> >> Result: growing a collection is always faster (or at least nearly equally fast)! >> >> Explanation: What makes preinitialized collections so slow is the fact the the firstIndex variable will be set to >> the first third of the array (3333 in this case). When the last position in the array is reached, all elements >> are copied to the beginning of the array (2n operations). This copy operation is really slow (which can be seen >> from the first example with an oversized collection that does not require copying because the last position >> of the array is never reached). >> >> >> Experiment (Pharo 4 on PharoVM): >> (Iâm using bigger numbers here to compensate for the faster VM :) ) >> >> >> [ 10000 timesRepeat: [ | c | c := OrderedCollection new: 1000000. >> 1 to: 100000 do: [ :i | c add: i ] ] ] timeToRun "0:00:01:09.225" >> >> [ 10000 timesRepeat: [ | c | c := OrderedCollection new: 100000. >> 1 to: 100000 do: [ :i | c add: i ] ] ] timeToRun "0:00:00:37.653" >> >> [ 10000 timesRepeat: [ | c | c := OrderedCollection new: 0. >> 1 to: 100000 do: [ :i | c add: i ] ] ] timeToRun "0:00:00:40.152" >> >> >> >> [ 10000 timesRepeat: [ | c | c := OrderedCollection new: 10000. >> 1 to: 100000 do: [ :i | c add: i ] ] ] timeToRun "0:00:00:42.121â >> >> >> >> Result: growing a collection is easily fast enough, although minute performance gains are possible with preinitialized collections. >> >> Explanation: #makeRoomAtLast has been improved. Also: firstIndex is now set to the beginning of the array, preventing the copy >> operation that made the former measurements so slow. >> The run with the oversized collection is only so slow because it apparently takes a lot of time to assign the large array (?). >> >> >> Consequence of my little experiment: My initial implementation of the idea in you paper set the array in OrderedCollection to nil >> under the assumption that grow operations are very costly. That choice leads to many changes in methods of OrderedCollection >> where it is necessary to check if the array has been initialized yet. This introduces overhead and makes the code more error prone. >> I see now that it makes much more sense to use an empty array, the performance lost by growing ist neglectable. >> >> It is also interesting to note that there almost never seems to be a good reason to initialize an OrderedCollection with a large array. >> >> >> Cheers, >> Max > >

Jan. 15, 2015

Re: [Pharo-dev] Implementing lazy loading for expandable collections (part 2)

by Jimmie Houchin

I do not understand what is happening here. oc := OrderedCollection new: 10000. oc size. "0" a := Array new: 10000. a size. "10000" So it seems that the #new: isn't creating an OrderedCollection of the size we pass in. I discovered this when I attempted to do the identical test but with an Array instead of an OrderedCollection. Since the Array doesn't #add: I had to change the code to #at:put:. When I noticed all of the OC code did #add: even if supposedly setting its size to 10000(0). I tried to use #at:put: in the OrderedCollection but it failed because their was no index 1, because the size was still 0. I naively would have thought that OrderedCollection new: 10000 would return an OrderedCollection of 10000 empty/nil elements and that I could #at:put: into any of those 10000 slots and #add if I needed to go beyond those 10000. Tests done on a laptop with Windows 7, Pharo 4 latest image, latest stable vm, 3rd gen i7 processor, 12gb ram. I did all of the tests in Pharo 4 and added my Array test. 0:00:00:04.37 0:00:00:03.183 0:00:00:03.674 0:00:00:03.753 0:00:00:01.647 and with an Array instead of OrderedCollection So we can see if we know the max size and create the collection with that size it should improve performance. I also do not understand why Pharo is so slow on this? With the preallocated Array above it took 1.647 seconds. Python 3.4.2, 0.003 seconds with 10,000 ints, and 0.17 with 1,000,000 ints. Julia 3.5, 0.005 seconds with 1,000,000 Int64. Now I don't expect Pharo to keep up with Julia. But we aren't even in the neighborhood with Python. I really would like to use Pharo. It really is my favorite language and environment. But these performance numbers give me pause. Jimmie On 1/14/2015 3:53 AM, Max Leske wrote: > Hi Alex > > I thought the following little experiment might interest you. > > I was trying to find out (as per your suggestion) how big the difference would be between: > - setting the array in OrderedCollection to nil and initializing it to size 10 on first access > - initializing the array in OrderedCollection to size 0. > > Expectation: #grow will take time, ergo, using an empty array should be slower than using > a preallocated array. > > Experiment (Pharo 1.3 on SqueakVM): > > > [ 10000 timesRepeat: [ | c | c := OrderedCollection new: 100000. > 1 to: 10000 do: [ :i | c add: i ] ] ] timeToRun 17566 > > [ 10000 timesRepeat: [ | c | c := OrderedCollection new: 10000. > 1 to: 10000 do: [ :i | c add: i ] ] ] timeToRun 19717 > > [ 10000 timesRepeat: [ | c | c := OrderedCollection new: 0. > 1 to: 10000 do: [ :i | c add: i ] ] ] timeToRun 17598 > > > > [ 10000 timesRepeat: [ | c | c := OrderedCollection new: 1000. > 1 to: 10000 do: [ :i | c add: i ] ] ] timeToRun 18084 > > > > Result: growing a collection is always faster (or at least nearly equally fast)! > > Explanation: What makes preinitialized collections so slow is the fact the the firstIndex variable will be set to > the first third of the array (3333 in this case). When the last position in the array is reached, all elements > are copied to the beginning of the array (2n operations). This copy operation is really slow (which can be seen > from the first example with an oversized collection that does not require copying because the last position > of the array is never reached). > > > Experiment (Pharo 4 on PharoVM): > (Iâm using bigger numbers here to compensate for the faster VM :) ) > > > [ 10000 timesRepeat: [ | c | c := OrderedCollection new: 1000000. > 1 to: 100000 do: [ :i | c add: i ] ] ] timeToRun "0:00:01:09.225" > > [ 10000 timesRepeat: [ | c | c := OrderedCollection new: 100000. > 1 to: 100000 do: [ :i | c add: i ] ] ] timeToRun "0:00:00:37.653" > > [ 10000 timesRepeat: [ | c | c := OrderedCollection new: 0. > 1 to: 100000 do: [ :i | c add: i ] ] ] timeToRun "0:00:00:40.152" > > > > [ 10000 timesRepeat: [ | c | c := OrderedCollection new: 10000. > 1 to: 100000 do: [ :i | c add: i ] ] ] timeToRun "0:00:00:42.121â > > > > Result: growing a collection is easily fast enough, although minute performance gains are possible with preinitialized collections. > > Explanation: #makeRoomAtLast has been improved. Also: firstIndex is now set to the beginning of the array, preventing the copy > operation that made the former measurements so slow. > The run with the oversized collection is only so slow because it apparently takes a lot of time to assign the large array (?). > > > Consequence of my little experiment: My initial implementation of the idea in you paper set the array in OrderedCollection to nil > under the assumption that grow operations are very costly. That choice leads to many changes in methods of OrderedCollection > where it is necessary to check if the array has been initialized yet. This introduces overhead and makes the code more error prone. > I see now that it makes much more sense to use an empty array, the performance lost by growing ist neglectable. > > It is also interesting to note that there almost never seems to be a good reason to initialize an OrderedCollection with a large array. > > > Cheers, > Max

Jan. 15, 2015

Re: [Pharo-dev] Fixing DNU binding in GT and Nautilus

by kilon alios

what DNU means ? is it the same as MNU ? On Thu, Jan 15, 2015 at 6:07 PM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > Should be Alain's repo: > http://smalltalkhub.com/mc/AlainPlantec/Rubric/main/ > If you do not have access I can commit the change for you. > > On Thu, Jan 15, 2015 at 5:03 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> The fix is in 4.0 446 but only for SmalltalkEditor. Where should we put >> the fix for RubSmalltalkEditor? >> >> 2015-01-14 22:49 GMT+01:00 stepharo <stepharo(a)free.fr>: >> >>> Thanks marcus >>> >>> I just open another one :( because I houtgh that my mail did go through. >>> I will close it. >>> >>> Le 14/1/15 13:02, Marcus Denker a Ã©crit : >>> >>> I have opened an issue for this: >>> >>> >>> https://pharo.fogbugz.com/f/cases/14731/Fixing-DNU-binding-in-GT-and-Nautil… >>> >>> >>> On 13 Jan 2015, at 20:11, stepharo <stepharo(a)free.fr> wrote: >>> >>> Hi >>> >>> in nautilus method pane and GT, when I select a global variable such as >>> >>> SystemOrganization and press command B + N >>> >>> I get DNU binding. >>> Apparently this DNU only happen when the name does not match any class >>> substring >>> Transcript or Undeclared will not raise an error because we have classes >>> having name matching the expression. >>> >>> Fixed included. >>> >>> PS: I'm dead after 1h30 train delay (after giving 6 hours lecture) >>> today. So this mail will be sent whenever I get connected. >>> >>> Stef >>> <FixDNUBinding.cs> >>> >>> >>> >>> >> >

Jan. 15, 2015