2015-07-01 7:46 GMT+02:00 Jan Blizni��enko <bliznjan@fit.cvut.cz>:

Sounds good, could I try it and run all those benchmarks etc. on it on my
PCs?

Jan

With this:
http://stackoverflow.com/questions/14290337/is-fwrite-faster-than-writefile-in-windows

It seems this all comes down to calling FlushFileBuffers.

You can check what would happen if we just disabling the explicit flushing
(comment out��
self primFlush: fileID
in StandardFileStream>>#flush)

and run the benchmarks.

(Of course, I don't know what side effects this have, *I* think WriteFile calls flush on

its own, and of course *if* this solves the problem, we can not just disable call to flush in the

image, but have to change the windows file plugin).

��

Nicolai Hess wrote
> Yes, the vm primitives, like I already told some messages above.
> FilePrimitives ARE slow on windows.
>
> We may get better performance, if we disable windows file cache/buffering
> and use slightly different ways to do the CreateFile and WriteFile
> calls, and do the buffering on our own, but this is not easy.
>
> Luckily (?), this may be alread work if we use the std file api (?)
>
> A small dirty test:
>
> store bench
> latest vm ->�� '22.098 per second'
> modified vm -> '31,027 per second'
>
> (in the modified vm I replaced all file operation from
> sqWin32FilePrims.c
> with the code from
> sqFilePluginBasicPrims.c)
>
> The result may seem strange, because both implementation will actually use
> win32s CreateFile/WriteFile methods, but
> maybe the second one uses better caching/buffering.
>
> nicolai

--
View this message in context: http://forum.world.st/Slow-compilation-on-one-of-my-Windows-PCs-tp4834668p4835032.html

Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.