2015-07-01 7:46 GMT+02:00 Jan Blizničenko <blizn...@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. > >
