[Bob Kline]
> ...
> I have made some progress in my debugging of the problem. In fact it
> appears that the problem stems from a wide discrepancy in the amount of
> time consumed by a call to fopen() on the two machines. A test repro
> written in C with loops to repeatedly attempt to open the fi
On Tue, 8 Jan 2002, Bob Kline wrote:
> On Tue, 8 Jan 2002, Tim Peters wrote:
> > Are you running a virus scanner on this machine? Some interfere
> > enormously with file operations.
>
> Both machines are running the same virus software, controlled by the
> network domain admin. I'll push some m
On Tue, 8 Jan 2002, Tim Peters wrote:
> [Bob Kline]
> > ...
> > I have made some progress in my debugging of the problem. In fact it
> > appears that the problem stems from a wide discrepancy in the amount of
> > time consumed by a call to fopen() on the two machines. A test repro
> > written i
On Tue, 8 Jan 2002, Andy Robinson wrote:
> This could mean that Bob has copied his Python executable to
> c:\winnt\system32, to make sure it is always available from a DOS
> prompt. I think we recommneded something heinous like this in PPW32
> :-(
Somebody actually did that to me with Perl DLLs
On Tue, 8 Jan 2002, Jason Orendorff wrote:
> > I tried breaking down the load times for the separate Python modules, to
> > see if one of them were doing something differently from the others, but
> > the extra load time seems to be spread out fairly evenly between them,
> > making it look more l
> Off topic because you said that that does not affec the loading time but:
> I don't know what c:\winnt\system32 should be there. It is not in
> my Python
> installation so it is not a std Python (or ActivePython) thing. Look in
> HLKM/Software/Python/PythonCore/X.X/PythonPath/. Do any of the
On Tue, 8 Jan 2002, Trent Mick wrote:
> > There is one odd discrepancy between the (newer) problem machine and the
> > development machine for sys.path: on the development machine the second
> > element (c:\winnt\system32) is not present. Removing it does not
> > eliminate the slow module loadin
On Tue, Jan 08, 2002 at 02:26:04PM -0500, Bob Kline wrote:
> On Tue, 8 Jan 2002, Trent Mick wrote:
>
> > > 2. What other tools or procedures can I use to delve further into
> > >this problem to track down its cause myself?
> >
> > You could look at the Python profiler and compare the profile
On Tue, 8 Jan 2002, Schollnick, Benjamin wrote:
> This is probably a complete red herring
>
> Use the Find File tool to check for:
>
> python*.dll
>
> I would bet you that you have a older DLL on your system...
>
> I've had a few cases where I've replaced my python installation with
> a
On Tue, 8 Jan 2002, Trent Mick wrote:
> > 2. What other tools or procedures can I use to delve further into
> >this problem to track down its cause myself?
>
> You could look at the Python profiler and compare the profile for a
> run on the two machines.
Well, the profiler shows big differen
Bob Kline wrote:
> So, my three questions are:
>
> 1. Does this description ring any bells, reminding you of similar
>problem reports for which you might have a solution?
No, I have not heard of anything similar.
>
> 2. What other tools or procedures can I use to delve further into
>th
older DLL.
- Benjamin
-Original Message-
From: Bob Kline [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 07, 2002 4:56 PM
To: [EMAIL PROTECTED]
Cc: Peter Zhang
Subject: Mysterious delay in Python module loading
I just noticed that on one of our servers Python (ActiveState version
2.1.1, latest
I just noticed that on one of our servers Python (ActiveState version
2.1.1, latest build) is taking an order of magnitude longer loading
standard Python modules than is normal. Most of our development is done
on a 4-way Intel 400MHz box running Windows 2000 Server, latest service
pack. On this
13 matches
Mail list logo
