[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
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 newer version, and had a older DLL.
- Benjami
12 matches
Mail list logo
