#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.
On 02 Jul 2015, at 17:46, Jan BlizniÄenko <bliznjan@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-tp4834668p48... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.