2015-07-02 19:01 GMT+02:00 Sven Van Caekenberghe <sven@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 <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-tp4834668p4835421.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.