2015-07-02 19:01 GMT+02:00 Sven Van Caekenberghe <s...@stfx.eu>: > #flush on a stream means pushing all data to the final destination, > clearing buffers, doing actual network transfers. > > What can happen when you disable that ? > > That some data does not arrive where it should I guess. > > Mind that #close most of the time does an automatic/implicit #flush. > > Anyway, I don't think disabling #flush is a real solution. >
+1 Maybe it is enough, if we remove the call to "self flush" in WriteStream>>#nextChunkPut: ? I see that squeak does not call flush, and :) in Squeak WriteStream>>#flush is empty (!) (But I think in squeak and pharo are many differences for stream and source/changes handling) > > > On 02 Jul 2015, at 17:46, Jan Blizničenko <blizn...@fit.cvut.cz> wrote: > > > > I'm experimenting with commenting the flush automatically by startup > script > > and loading now takes reasonable amount of time ( StandardFileStream > > compile: 'flush'. ). > > I haven't found any drawbacks so far, but it doesn't mean anything and > that > > "manual" flushing probably is there for a reason, what is the reason? > > > > Jan > > > > > > Jan Blizničenko wrote > >> I tried commenting primFlush: fileID in StandardFileStream>>#flush on my > >> desktop PC and the "store" benchmark's speed improved significantly. > >> > >> Original result on Windows 7: 11 per sec > >> Result without flushing on Windows 7: 9 430 per sec > >> Original result on Linux Mint 17: 26 590 per sec > >> Result without flushing on Linux Mint 17: 34 879 per sec > >> > >> Mentioned Linux Mint is in VirtualBox on the same PC. > >> > >> Also loading of Roassal2 now takes 58 seconds insted of 386. > >> > >> Jan > > > > > > > > > > > > -- > > View this message in context: > http://forum.world.st/Slow-compilation-on-one-of-my-Windows-PCs-tp4834668p4835421.html > > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > >
