On dim. 18 mars 2018 at 11:18, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 18 Mar 2018, at 11:16, Guillermo Polito <guillermo.polito@inria.fr> wrote:
Yes, looking at the stack in the profiler, there is a buffered stream missing in there. The thing is that source/changes file reading/writing required special attention in the migration (or the image became unusable :)).
I'll fix it tomorrow first thing in the morning, if you can wait a couple of hours ;)
I'll post the fixes later on. Was pretty easy, needs a 2nd pair of eyes.
Thank you for the fast fix :) And I did not add a number too much :) look at the other profiler I send. This is why I found it as a really huge lost of performances. Probably Windows who is slower on file reading even with AV disable for the .sources.
Guille
On Sun, Mar 18, 2018 at 10:54 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 18 Mar 2018, at 00:03, Cyril Ferlicot <cyril.ferlicot@gmail.com> wrote:
Time to execute: SystemNavigation new browseMethodsWithSourceString: 'Method source with it' matchCase: false
Pharo 6.1: 2480ms
Pharo 7: 132041ms
You didn't type a digit too much, did you ? That is 2 orders of magnitude, maybe on Windows ;-)
https://pharo.manuscript.com/f/cases/21612/Performances-regression-on-source...
I can confirm that the slowdown pre/post recent file/stream changes in
Pharo 7 is about 1 order of magnitude (x10).
There is however no fundamental problem, since the following are equally
fast (~ 1s) in both cases (using old/new streams).
SmalltalkImage current sourcesFile asFileReference readStreamDo: [ :in |
[ in atEnd ] whileFalse: [ in next ] ]
I think there is a ZnBufferedReadStream missing (between the
ZnCharacterReadStream and the primitive File stream) in SourceFile>>#tryOpenReadOnly:
Sven
--
Guille Polito
Research Engineer French National Center for Scientific Research - http://www.cnrs.fr
Web: http://guillep.github.io Phone: +33 06 52 70 66 13
-- Cyril Ferlicot https://ferlicot.fr