RE: Help with slow startup

[Jan Dubois]

On Mon, 18 Jan 2010, Michael Ellery wrote:
 
 Thanks for that patch. I've patched the file on my system and rebooted -
 now I see times shown below. Now my first startup time is only double my
 steady state time, which seems to be an improvement (previous run was
 more than 3 times the subsequent time). However, since the patch appears
 in a .pm file, shouldn't this change have an impact *every time* the
 script is executed, or is this code only loaded under certain conditions?

I suspect that there is some OS level caching going on.  I think some of
the type libraries installed on your machine are stored on a network drive
and not on a local disk.

I don't have time to work out right now if we need those file tests at all,
but I have another idea that might speed up the code some more:  In front
of the line that you modified with the patch insert the following line:

local ${^WIN32_SLOPPY_STAT} = 1;

Please let me know if this has any effect on your startup time.

Cheers,
-Jan

___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Re: Help with slow startup

[Michael Ellery]

On 1/19/2010 4:17 PM, Jan Dubois wrote:
 On Mon, 18 Jan 2010, Michael Ellery wrote:

 Thanks for that patch. I've patched the file on my system and rebooted -
 now I see times shown below. Now my first startup time is only double my
 steady state time, which seems to be an improvement (previous run was
 more than 3 times the subsequent time). However, since the patch appears
 in a .pm file, shouldn't this change have an impact *every time* the
 script is executed, or is this code only loaded under certain conditions?

 I suspect that there is some OS level caching going on.  I think some of
 the type libraries installed on your machine are stored on a network drive
 and not on a local disk.

 I don't have time to work out right now if we need those file tests at all,
 but I have another idea that might speed up the code some more:  In front
 of the line that you modified with the patch insert the following line:

  local ${^WIN32_SLOPPY_STAT} = 1;

 Please let me know if this has any effect on your startup time.

 Cheers,
 -Jan



Jan,

thanks again for these mysterious patches. Yes, this had a positive 
effect - now with this patch plus the previous patch in place, my first 
vs. subsequent run times are 15s vs 10s. This is a considerable 
improvement over the 30s vs 10s that I was previously seeing.

Can you shed a little light on what this WIN32_SLOPPY_STAT does - I'm 
guessing it uses a faster set of APIs for gathering file stat info - 
perhaps at the cost of accuracy?

As for typelibrary location - all of my com objects and typelibs should 
be local (I build debug locally). The only thing I'm aware of that 
*could* be pulled from the network are the debug symbols from microsoft, 
which we store on a network share since they are rather large. This slow 
startup time is observed with release builds of our objects too (I have 
not yet tried your patches with a release build..), and those should 
have no network dependencies. Our com objects are all compiled code and 
the typelib info is built-in, so we don't ship separate typelib files (I 
don't know if that makes any difference here...)

Thanks again for your help.

-Mike
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

RE: Help with slow startup

[Jan Dubois]

On Tue, 19 Jan 2010, Michael Ellery wrote:
 Can you shed a little light on what this WIN32_SLOPPY_STAT does - I'm
 guessing it uses a faster set of APIs for gathering file stat info -
 perhaps at the cost of accuracy?

The normal Perl implementation of stat() on Windows actually opens
the file.  That seems to be the only way to make sure updates from
hardlinks get propagated.  But hardlinks are rarely used on Windows,
and information like nlink (the hardlink count from the stat buffer
even less so), so for most purposes not doing the file open is not
a problem.

Of course the largest savings come from not opening a file that is
on a network share and not local, because those open()s are really
slow.

Cheers,
-Jan


___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs