Smalltalk › Pharo › Pharo Smalltalk Developers

[VM] Windows VM SurfacePlugin.dll LoadLibrary failure

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

13 messages Options

Peter Uhnak

[VM] Windows VM SurfacePlugin.dll LoadLibrary failure

Hi,

recently (couple of days ago) sometimes when I start Pharo there's a box at the bottom "Debug console" with the following info

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# Debug console
# To close: F2 -> 'debug options' -> 'show output console'
# To disable: F2 -> 'debug options' -> 'show console on errors'
LoadLibrary(SurfacePlugin) (998: Invalid access to memory location.

)
LoadLibrary(SurfacePlugin.dll) (998: Invalid access to memory location.

)
LoadLibrary(SurfacePlugin) (998: Invalid access to memory location.

)
LoadLibrary(SurfacePlugin.dll) (998: Invalid access to memory location.

)
LoadLibrary(SurfacePlugin) (998: Invalid access to memory location.

)
LoadLibrary(SurfacePlugin.dll) (998: Invalid access to memory location.

)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I have Windows 10 & VM Version: Cog Spur VM 5.0 (release) from Feb 3 2017 (downloaded from files.pharo.org)

This error results in Athens (and Roassal) not working, although Pharo itself seems fine.

Reopening the image has no effect, and the only resolution is to do a system reboot.

There is also crash.dmp from Feb 12 (possibly the day it started) containing

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sun Feb 12 23:10:24 2017

Exception code: C0000005
Exception addr: 0040BDD0
Access violation (write access) at 00AFF43C
EAX:FFFFFFFF EBX:74329850 ECX:549D7EBE EDX:00AFF43C
ESI:74315F70 EDI:00489DB9 EBP:0887FF94 ESP:0887FF54
EIP:0040BDD0 EFL:00010206
FP Control: 0000027F
FP Status: 00000000
FP Tag: 0000FFFF

Crashed in some other thread
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Makes me wonder whether the SurfacePlugin.dll didn't somehow get corrupted... but then again there's no modification date change on the dll file, nor would it explain why rebooting fixes it.

Thanks,
Peter

CyrilFerlicot

Re: [VM] Windows VM SurfacePlugin.dll LoadLibrary failure

On 16/02/2017 11:06, Peter Uhnak wrote:

> Hi,
>
> recently (couple of days ago) sometimes when I start Pharo there's a box at the bottom "Debug console" with the following info
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> # Debug console
> # To close: F2 -> 'debug options' -> 'show output console'
> # To disable: F2 -> 'debug options' -> 'show console on errors'
> LoadLibrary(SurfacePlugin) (998: Invalid access to memory location.
>
> )
> LoadLibrary(SurfacePlugin.dll) (998: Invalid access to memory location.
>
> )
> LoadLibrary(SurfacePlugin) (998: Invalid access to memory location.
>
> )
> LoadLibrary(SurfacePlugin.dll) (998: Invalid access to memory location.
>
> )
> LoadLibrary(SurfacePlugin) (998: Invalid access to memory location.
>
> )
> LoadLibrary(SurfacePlugin.dll) (998: Invalid access to memory location.
>
> )
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> I have Windows 10 & VM Version: Cog Spur VM 5.0 (release) from Feb 3 2017 (downloaded from files.pharo.org)
>
> This error results in Athens (and Roassal) not working, although Pharo itself seems fine.
>
> Reopening the image has no effect, and the only resolution is to do a system reboot.
>
>
> There is also crash.dmp from Feb 12 (possibly the day it started) containing
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Sun Feb 12 23:10:24 2017
>
> Exception code: C0000005
> Exception addr: 0040BDD0
> Access violation (write access) at 00AFF43C
> EAX:FFFFFFFF EBX:74329850 ECX:549D7EBE EDX:00AFF43C
> ESI:74315F70 EDI:00489DB9 EBP:0887FF94 ESP:0887FF54
> EIP:0040BDD0 EFL:00010206
> FP Control: 0000027F
> FP Status: 00000000
> FP Tag: 0000FFFF
>
>
> Crashed in some other thread
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Makes me wonder whether the SurfacePlugin.dll didn't somehow get corrupted... but then again there's no modification date change on the dll file, nor would it explain why rebooting fixes it.
>
> Thanks,
> Peter
>

Hi,

I got the same problem with the latest vm some weeks ago on Windows 7.
It vanished by downloading a new vm some days after.

I did not try with the current latest. I'll maybe have the time to try
this week end.

--
Cyril Ferlicot

http://www.synectique.eu

2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France

signature.asc (817 bytes) Download Attachment

Peter Uhnak

Re: [VM] Windows VM SurfacePlugin.dll LoadLibrary failure

On Thu, Feb 16, 2017 at 12:19:00PM +0100, Cyril Ferlicot D. wrote:
>
> I got the same problem with the latest vm some weeks ago on Windows 7.
> It vanished by downloading a new vm some days after.

I've downloaded the latest VM and it works as expected. Thanks!

Peter

Peter Uhnak

Re: [VM] Windows VM SurfacePlugin.dll LoadLibrary failure

Well, I take that back.

Today I had the same issue (with the latest VM).
Closing the image and reopening it helped, but clearly there is something broken underneath.

Peter

On Wed, Feb 22, 2017 at 09:29:12PM +0100, Peter Uhnak wrote:
> On Thu, Feb 16, 2017 at 12:19:00PM +0100, Cyril Ferlicot D. wrote:
> >
> > I got the same problem with the latest vm some weeks ago on Windows 7.
> > It vanished by downloading a new vm some days after.
>
> I've downloaded the latest VM and it works as expected. Thanks!
>
> Peter

tinchodias

Re: [VM] Windows VM SurfacePlugin.dll LoadLibrary failure

Same here, in #60442.

Smalltalk vm version --->

"'CoInterpreter * VMMaker.oscog-EstebanLorenzano.2136 uuid: 40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 22 2017

StackToRegisterMappingCogit * VMMaker.oscog-EstebanLorenzano.2136 uuid: 40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 22 2017

VM: 201702221539 https://github.com/pharo-project/pharo-vm.git $ Date: Wed Feb 22 16:39:40 2017 +0100 $ Plugins: 201702221539 https://github.com/pharo-project/pharo-vm.git $

cmd ver --->

Microsoft Windows [Versión 10.0.14393]

Additionally:

And it takes >30 minutes to load Roassal2, while takes <1 minyte in Linux (same notebook). Script:

Gofer new

url: 'http://www.smalltalkhub.com/mc/ObjectProfile/Roassal2/main';

package: 'ConfigurationOfRoassal2';

load.

#ConfigurationOfRoassal2 asClass load.

Martin

On Fri, Feb 24, 2017 at 8:52 AM, Peter Uhnak <[hidden email]> wrote:

Well, I take that back.

Today I had the same issue (with the latest VM).
Closing the image and reopening it helped, but clearly there is something broken underneath.

Peter

On Wed, Feb 22, 2017 at 09:29:12PM +0100, Peter Uhnak wrote:
> On Thu, Feb 16, 2017 at 12:19:00PM +0100, Cyril Ferlicot D. wrote:
> >
> > I got the same problem with the latest vm some weeks ago on Windows 7.
> > It vanished by downloading a new vm some days after.
>
> I've downloaded the latest VM and it works as expected. Thanks!
>
> Peter

Peter Uhnak

Re: [VM] Windows VM SurfacePlugin.dll LoadLibrary failure

I still do see it ocassionally too... sometimes corelated to dual-booting and network interface fuckery (by that I mean that Windows doesn't detect network, or even wireless perhiperhals like mouse... but Windows 10 yay...)

for the load time... sometime firewall/AV can fuck it up... but generally it should be always slower than linux, because Windows can't files.

(I am using the latest VM usually)

Peter

On Thu, Mar 16, 2017 at 01:11:03AM -0300, Martin Dias wrote:

> Same here, in #60442.
>
> Smalltalk vm version --->
> "'CoInterpreter * VMMaker.oscog-EstebanLorenzano.2136 uuid:
> 40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 22 2017
> StackToRegisterMappingCogit * VMMaker.oscog-EstebanLorenzano.2136 uuid:
> 40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 22 2017
> VM: 201702221539 https://github.com/pharo-project/pharo-vm.git $ Date: Wed
> Feb 22 16:39:40 2017 +0100 $ Plugins: 201702221539
> https://github.com/pharo-project/pharo-vm.git $
> '"
>
> cmd ver --->
> Microsoft Windows [Versión 10.0.14393]
>
>
>
> Additionally:
>
> And it takes >30 minutes to load Roassal2, while takes <1 minyte in Linux
> (same notebook). Script:
>
> Gofer new
> url: 'http://www.smalltalkhub.com/mc/ObjectProfile/Roassal2/main';
> package: 'ConfigurationOfRoassal2';
> load.
> #ConfigurationOfRoassal2 asClass load.
>
>
>
> Martin
>
> On Fri, Feb 24, 2017 at 8:52 AM, Peter Uhnak <[hidden email]> wrote:
>
> > Well, I take that back.
> >
> > Today I had the same issue (with the latest VM).
> > Closing the image and reopening it helped, but clearly there is something
> > broken underneath.
> >
> > Peter
> >
> > On Wed, Feb 22, 2017 at 09:29:12PM +0100, Peter Uhnak wrote:
> > > On Thu, Feb 16, 2017 at 12:19:00PM +0100, Cyril Ferlicot D. wrote:
> > > >
> > > > I got the same problem with the latest vm some weeks ago on Windows 7.
> > > > It vanished by downloading a new vm some days after.
> > >
> > > I've downloaded the latest VM and it works as expected. Thanks!
> > >
> > > Peter
> >
> >

Eliot Miranda-2

Re: [VM] Windows VM SurfacePlugin.dll LoadLibrary failure

In reply to this post by tinchodias

Hi Martin,

hopefully the VMProfiler still runs on Windows so you could use it to profile the VM as it loads Rossal2 and I can help you decode the results. Alternatively you could use AndreasSystemProfiler and see which primitives are particularly expensive. But in any case, some kind of profiling would point to why things are so much slower on Windows.

On Wed, Mar 15, 2017 at 9:11 PM, Martin Dias <[hidden email]> wrote:

Same here, in #60442.

Smalltalk vm version --->
"'CoInterpreter * VMMaker.oscog-EstebanLorenzano.2136 uuid: 40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 22 2017
StackToRegisterMappingCogit * VMMaker.oscog-EstebanLorenzano.2136 uuid: 40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 22 2017
VM: 201702221539 https://github.com/pharo-project/pharo-vm.git $ Date: Wed Feb 22 16:39:40 2017 +0100 $ Plugins: 201702221539 https://github.com/pharo-project/pharo-vm.git $
'"

cmd ver --->
Microsoft Windows [Versión 10.0.14393]

Additionally:

And it takes >30 minutes to load Roassal2, while takes <1 minyte in Linux (same notebook). Script:

Gofer new
url: 'http://www.smalltalkhub.com/mc/ObjectProfile/Roassal2/main';
package: 'ConfigurationOfRoassal2';
load.
#ConfigurationOfRoassal2 asClass load.

Martin

On Fri, Feb 24, 2017 at 8:52 AM, Peter Uhnak <[hidden email]> wrote:
Well, I take that back.

Today I had the same issue (with the latest VM).
Closing the image and reopening it helped, but clearly there is something broken underneath.

Peter

On Wed, Feb 22, 2017 at 09:29:12PM +0100, Peter Uhnak wrote:
> On Thu, Feb 16, 2017 at 12:19:00PM +0100, Cyril Ferlicot D. wrote:
> >
> > I got the same problem with the latest vm some weeks ago on Windows 7.
> > It vanished by downloading a new vm some days after.
>
> I've downloaded the latest VM and it works as expected. Thanks!
>
> Peter

_,,,^..^,,,_

best, Eliot

CyrilFerlicot

Re: [VM] Windows VM SurfacePlugin.dll LoadLibrary failure

In reply to this post by tinchodias

Le 16/03/2017 à 05:11, Martin Dias a écrit :
> And it takes >30 minutes to load Roassal2, while takes <1 minyte in
> Linux (same notebook). Script:
>

Do you have an anti-virus? If yes did you excluded the .changes and ombu
files from the files to check? If not the anti-virus might analyze your
file at each compilation.

--
Cyril Ferlicot

http://www.synectique.eu

2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France

signature.asc (836 bytes) Download Attachment

philippeback

Re: [VM] Windows VM SurfacePlugin.dll LoadLibrary failure

In reply to this post by Eliot Miranda-2

How does one use the VMProfiler?

Phil

On Thu, Mar 16, 2017 at 9:01 PM, Eliot Miranda <[hidden email]> wrote:

Hi Martin,

hopefully the VMProfiler still runs on Windows so you could use it to profile the VM as it loads Rossal2 and I can help you decode the results. Alternatively you could use AndreasSystemProfiler and see which primitives are particularly expensive. But in any case, some kind of profiling would point to why things are so much slower on Windows.

On Wed, Mar 15, 2017 at 9:11 PM, Martin Dias <[hidden email]> wrote:
Same here, in #60442.

Smalltalk vm version --->
"'CoInterpreter * VMMaker.oscog-EstebanLorenzano.2136 uuid: 40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 22 2017
StackToRegisterMappingCogit * VMMaker.oscog-EstebanLorenzano.2136 uuid: 40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 22 2017
VM: 201702221539 https://github.com/pharo-project/pharo-vm.git $ Date: Wed Feb 22 16:39:40 2017 +0100 $ Plugins: 201702221539 https://github.com/pharo-project/pharo-vm.git $
'"

cmd ver --->
Microsoft Windows [Versión 10.0.14393]

Additionally:

And it takes >30 minutes to load Roassal2, while takes <1 minyte in Linux (same notebook). Script:

Gofer new
url: 'http://www.smalltalkhub.com/mc/ObjectProfile/Roassal2/main';
package: 'ConfigurationOfRoassal2';
load.
#ConfigurationOfRoassal2 asClass load.

Martin

On Fri, Feb 24, 2017 at 8:52 AM, Peter Uhnak <[hidden email]> wrote:
Well, I take that back.

Today I had the same issue (with the latest VM).
Closing the image and reopening it helped, but clearly there is something broken underneath.

Peter

On Wed, Feb 22, 2017 at 09:29:12PM +0100, Peter Uhnak wrote:
> On Thu, Feb 16, 2017 at 12:19:00PM +0100, Cyril Ferlicot D. wrote:
> >
> > I got the same problem with the latest vm some weeks ago on Windows 7.
> > It vanished by downloading a new vm some days after.
>
> I've downloaded the latest VM and it works as expected. Thanks!
>
> Peter

--
_,,,^..^,,,_
best, Eliot

tinchodias

Re: [VM] Windows VM SurfacePlugin.dll LoadLibrary failure

In reply to this post by CyrilFerlicot

Hi all. I rarely use Windows but this night entered again to repeat the load test in Pharo.

Cyril: I uninstalled the antivirus and excluded .changes and .images files in the "Windows Defender" (didn't know it exists). I may note some speed up but not much, so it wasn't THE solution.

Peter: I didn't check firewall but "Compiling methods..." is what stays on screen so it shouldn't be the network.

Eliot: this time I profiled it and can highlight from report that Leaves shows 91% in StandardFileStream>>primFlush:. I guess it isn't too surprising since file writing is expensive but it's a lot. However I didn't compare it yet with the respective report in linux. For the record, I attach the report.

Code evaluated:

AndreasSystemProfiler spyOn: [

Gofer new

url: 'http://www.smalltalkhub.com/mc/ObjectProfile/Roassal2/main';

package: 'ConfigurationOfRoassal2';

load.

#ConfigurationOfRoassal2 asClass load.]

Regards

Martín

On Thu, Mar 16, 2017 at 8:03 PM, Cyril Ferlicot D. <[hidden email]> wrote:

Le 16/03/2017 à 05:11, Martin Dias a écrit :
> And it takes >30 minutes to load Roassal2, while takes <1 minyte in
> Linux (same notebook). Script:
>

Do you have an anti-virus? If yes did you excluded the .changes and ombu
files from the files to check? If not the anti-virus might analyze your
file at each compilation.

--
Cyril Ferlicot

http://www.synectique.eu

2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France

profile.txt (36K) Download Attachment

Nicolas Cellier

Re: [VM] Windows VM SurfacePlugin.dll LoadLibrary failure

AFAIR, flushing after each write was a workaround against some linux problem.

I think that flush is not exagerately expensive on linux, because there's a difference between flush (transfer data from user space buffers to kernel space buffers) and sync (transfer data to the disc).

In Win32 VM, the fileFlush and fileSync primitives do the same call to FlushFileBuffers.

The msdn tells it's a bad thing to repeatedly call FlushFileBuffers
https://msdn.microsoft.com/en-us/library/windows/desktop/aa364439(v=vs.85).aspx

I don't see such thing as a "cheap" flush on windows.

But do we really need to flush?
Couldn't we rather implement a linuxWorkaroundFlush: aFile method that would flush on linux and do nothing anywhere else?

2017-04-01 6:40 GMT+02:00 Martin Dias <[hidden email]>:

Hi all. I rarely use Windows but this night entered again to repeat the load test in Pharo.

Cyril: I uninstalled the antivirus and excluded .changes and .images files in the "Windows Defender" (didn't know it exists). I may note some speed up but not much, so it wasn't THE solution.

Peter: I didn't check firewall but "Compiling methods..." is what stays on screen so it shouldn't be the network.

Eliot: this time I profiled it and can highlight from report that Leaves shows 91% in StandardFileStream>>primFlush:. I guess it isn't too surprising since file writing is expensive but it's a lot. However I didn't compare it yet with the respective report in linux. For the record, I attach the report.

Code evaluated:
AndreasSystemProfiler spyOn: [
Gofer new
url: 'http://www.smalltalkhub.com/mc/ObjectProfile/Roassal2/main';
package: 'ConfigurationOfRoassal2';
load.
#ConfigurationOfRoassal2 asClass load.]

Regards
Martín

On Thu, Mar 16, 2017 at 8:03 PM, Cyril Ferlicot D. <[hidden email]> wrote:
Le 16/03/2017 à 05:11, Martin Dias a écrit :
> And it takes >30 minutes to load Roassal2, while takes <1 minyte in
> Linux (same notebook). Script:
>

Do you have an anti-virus? If yes did you excluded the .changes and ombu
files from the files to check? If not the anti-virus might analyze your
file at each compilation.

--
Cyril Ferlicot

http://www.synectique.eu

2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France

Nicolas Cellier

Re: [VM] Windows VM SurfacePlugin.dll LoadLibrary failure

In squeak, that would be:

Frank Shearar uploaded a new version of Collections to project The Trunk:
http://source.squeak.org/trunk/Collections-fbs.513.mcz

==================== Summary ====================

Name: Collections-fbs.513
Author: fbs
Time: 26 April 2013, 11:13:00.656 am
UUID: dba4f808-6844-414c-a5bf-5cda0cf4e342
Ancestors: Collections-bf.512

This fixes the recent report of an Ubuntu 13.04 machine not being able to save a class comment.

https://bugzilla.redhat.com/show_bug.cgi?id=956376

I presume that the workaround in Pharo appeared more or less simultaneously since Pavel was active in the bug report.

Now we re-discover that such workaround can have side effects...

2017-04-01 10:06 GMT+02:00 Nicolas Cellier <[hidden email]>:

AFAIR, flushing after each write was a workaround against some linux problem.
I think that flush is not exagerately expensive on linux, because there's a difference between flush (transfer data from user space buffers to kernel space buffers) and sync (transfer data to the disc).

In Win32 VM, the fileFlush and fileSync primitives do the same call to FlushFileBuffers.
The msdn tells it's a bad thing to repeatedly call FlushFileBuffers
https://msdn.microsoft.com/en-us/library/windows/desktop/aa364439(v=vs.85).aspx
I don't see such thing as a "cheap" flush on windows.

But do we really need to flush?
Couldn't we rather implement a linuxWorkaroundFlush: aFile method that would flush on linux and do nothing anywhere else?

2017-04-01 6:40 GMT+02:00 Martin Dias <[hidden email]>:
Hi all. I rarely use Windows but this night entered again to repeat the load test in Pharo.

Cyril: I uninstalled the antivirus and excluded .changes and .images files in the "Windows Defender" (didn't know it exists). I may note some speed up but not much, so it wasn't THE solution.

Peter: I didn't check firewall but "Compiling methods..." is what stays on screen so it shouldn't be the network.

Eliot: this time I profiled it and can highlight from report that Leaves shows 91% in StandardFileStream>>primFlush:. I guess it isn't too surprising since file writing is expensive but it's a lot. However I didn't compare it yet with the respective report in linux. For the record, I attach the report.

Code evaluated:
AndreasSystemProfiler spyOn: [
Gofer new
url: 'http://www.smalltalkhub.com/mc/ObjectProfile/Roassal2/main';
package: 'ConfigurationOfRoassal2';
load.
#ConfigurationOfRoassal2 asClass load.]

Regards
Martín

On Thu, Mar 16, 2017 at 8:03 PM, Cyril Ferlicot D. <[hidden email]> wrote:
Le 16/03/2017 à 05:11, Martin Dias a écrit :
> And it takes >30 minutes to load Roassal2, while takes <1 minyte in
> Linux (same notebook). Script:
>

Do you have an anti-virus? If yes did you excluded the .changes and ombu
files from the files to check? If not the anti-virus might analyze your
file at each compilation.

--
Cyril Ferlicot

http://www.synectique.eu

2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France

David T. Lewis

File I/O performance (Re: [VM] Windows VM SurfacePlugin.dll LoadLibrary failure)

In reply to this post by Nicolas Cellier

On Sat, Apr 01, 2017 at 10:06:34AM +0200, Nicolas Cellier wrote:
> AFAIR, flushing after each write was a workaround against some linux
> problem.

This was specifically for the case of writing a chunk to e.g. the changes
file. The extra flush for that case is protecting for two processes writing
to the same stream. This would not affect overall read/write performance
though.

> I think that flush is not exagerately expensive on linux, because there's a
> difference between flush (transfer data from user space buffers to kernel
> space buffers) and sync (transfer data to the disc).

The Windows VM uses a different FilePlugin. The I/O calls are made at the
HANDLE level, not at the (FILE *) level as in the Unix plugin. A HANDLE on
Windows would be loosely equivalent to a file descriptor number on Unix.

If #primitiveFileFlush is intended to mean "flush everything from the VM out
to the operating system", and #primitiveFileSync is intended to mean "tell the
operating system to flush it all way to disk", then flush would be a no-op
on Windows, and you would call the sync primitive only in cases where you
really need to guarantee a flush to disk.

An interesting project would be to adapt the Unix plugin to run on Windows
(maybe it already just works, I never tried), or conversely to write a Unix
plugin that reads and writes to the file descriptor level as in done with
the Windows plugin.

My guess is that both approaches are valid, and they probably will have
differing performance advantages based on the I/O workload. But someone
would have to try it to find out :-)

Dave

>
> In Win32 VM, the fileFlush and fileSync primitives do the same call to
> FlushFileBuffers.
> The msdn tells it's a bad thing to repeatedly call FlushFileBuffers
> https://msdn.microsoft.com/en-us/library/windows/desktop/aa364439(v=vs.85).aspx
> I don't see such thing as a "cheap" flush on windows.
>
> But do we really need to flush?
> Couldn't we rather implement a linuxWorkaroundFlush: aFile method that
> would flush on linux and do nothing anywhere else?
>
> 2017-04-01 6:40 GMT+02:00 Martin Dias <[hidden email]>:
>
> > Hi all. I rarely use Windows but this night entered again to repeat the
> > load test in Pharo.
> >
> > Cyril: I uninstalled the antivirus and excluded .changes and .images files
> > in the "Windows Defender" (didn't know it exists). I may note some speed up
> > but not much, so it wasn't THE solution.
> >
> > Peter: I didn't check firewall but "Compiling methods..." is what stays on
> > screen so it shouldn't be the network.
> >
> > Eliot: this time I profiled it and can highlight from report that Leaves
> > shows 91% in StandardFileStream>>primFlush:. I guess it isn't too
> > surprising since file writing is expensive but it's a lot. However I didn't
> > compare it yet with the respective report in linux. For the record, I
> > attach the report.
> >
> > Code evaluated:
> > AndreasSystemProfiler spyOn: [
> > Gofer new
> > url: 'http://www.smalltalkhub.com/mc/ObjectProfile/Roassal2/main';
> > package: 'ConfigurationOfRoassal2';
> > load.
> > #ConfigurationOfRoassal2 asClass load.]
> >
> > Regards
> > Mart??n
> >
> >
> > On Thu, Mar 16, 2017 at 8:03 PM, Cyril Ferlicot D. <
> > [hidden email]> wrote:
> >
> >> Le 16/03/2017 ?? 05:11, Martin Dias a ??crit :
> >> > And it takes >30 minutes to load Roassal2, while takes <1 minyte in
> >> > Linux (same notebook). Script:
> >> >
> >>
> >> Do you have an anti-virus? If yes did you excluded the .changes and ombu
> >> files from the files to check? If not the anti-virus might analyze your
> >> file at each compilation.
> >>
> >> --
> >> Cyril Ferlicot
> >>
> >> http://www.synectique.eu
> >>
> >> 2 rue Jacques Pr??vert 01,
> >> 59650 Villeneuve d'ascq France
> >>
> >>
> >