exec taking a long time under WISH, but not with TCLSH
MB
I've got a program that generates a .csv file which I'd like to open
with Excel.
I put together a quick command line demo using tclsh and it worked
perfectly. When I try running it under WISH it takes 30 seconds to
pull up the file.
I've boiled it down to the following line of code.
from a directory that contains a 3 line csv file called output.csv
tclsh85
% time {eval exec [auto_execok start] output.csv}
266000 microseconds per iteration
% exit
(works pretty much instantly).
wish85
in the console window...
% time {eval exec [auto_execok start] output.csv}
30188000 microseconds per iteration
%
the console locks up and doesn't return for 30 seconds (when excel
finally opens).
this was running tcl 8.5.4 on windows XP.
the same thing happens if I try.
tclsh85
% package require Tk
8.5.4
% time {eval exec [auto_execok start] output.csv}
30375000 microseconds per iteration
The 30 seconds makes me think it's some kind of network timeout. I'm
just not sure why I only see it with wish (or why it would try and
make any kind of network call).
I tried running on a newer machine running vista and got similar
results.
.1 seconds with tclsh, and almost 6 seconds using WISH.
Everything is running the 8.5.4 version of tcl from activestate.
Mark Janssen
> tir...@gmail.com wrote:
>
> > I've got a program that generates a .csv file which I'd like to open
> > with Excel.
>
> > I put together a quick command line demo using tclsh and it worked
> > perfectly. When I try running it under WISH it takes 30 seconds to
> > pull up the file.
>
> This sounds familiar. I saw something like it a while ago, maybe Tcl 8.3.2.
> Very slow startup times for Word or Excel when started from wish, using a
> file's extension to select the program. (You are doing {START file.csv}, I
> was doing {$env(COMSPEC) file.doc}, but it could be the same thing.) I saw
> 1-4 minutes, but that could have been on much slower boxes.
>
> Could you try coding it to run the Excel program directly, just to see what
> happens? Like {exec .../excel.exe file.csv}. When I did that it started
> instantly. It might help identify the problem, and no I don't think it is
> network related.
I am not sure about the exact reason, but adding a & at the end makes
starting programs with start in wish much faster. If you don't need
the output, you could try with [exec .../excel.exe file.csv &]
Mark
Larry W. Virden
> The 30 seconds makes me think it's some kind of network timeout. I'm
> just not sure why I only see it with wish (or why it would try and
> make any kind of network call).
I'm curious - do you see the same kind of difference if you are
invoking something other than Excel? Perhaps try invoking some sort of
non-GUI program.
As for your suspicision about network timeout - would starting up the
Windows task manager and watching the process and the network activity
answer that question?
Are there any tools that would allow a Windows user to track where
time is being spent in tcl program , similar to the system call
tracing programs on some unix systems?
Alexandre Ferrieux
> On Sep 20, 10:30 pm, MB <tir...@gmail.com> wrote:
>
> > The 30 seconds makes me think it's some kind of network timeout. I'm
> > just not sure why I only see it with wish (or why it would try and
> > make any kind of network call).
>
> I'm curious - do you see the same kind of difference if you are
> invoking something other than Excel? Perhaps try invoking some sort of
> non-GUI program.
I tried on my XPSP2 Dell 620 laptop and the free Word viewer, and I
did observe the very same thing !
> As for your suspicision about network timeout - would starting up the
> Windows task manager and watching the process and the network activity
> answer that question?
>
> Are there any tools that would allow a Windows user to track where
> time is being spent in tcl program , similar to the system call
> tracing programs on some unix systems?
I immediately started StraceNTx, but the tool is a very frustrating
ersatz of strace. In particular, no timestamps, and I don't have the
courage to write a filter excluding all those syscalls in the idle
loop of Wish. Of course the trace can be saved in a file, but without
timestamps it is a tiny needle and a huge haystack...
If anybody knows about a newer version (or another tool) than
StraceNTx 0.8b2, please by all means say so.
-Alex
Roy Terry
wrote:
I'm not at all sure what StraceNTx really does, but the Sysinternals
family of utilities could possibly catch the issue:
http://technet.microsoft.com/en-us/sysinternals/677683af-3f5e-42ea-8116-9c92acd2c271.aspx
(Independently developed and then purchased by MS but sill all free)
Alexandre Ferrieux
>
> (Independently developed and then purchased by MS but sill all free)
Yes, I tried ProcMon first, but that's too coarse :-(
Indeed you only get to I/O, filesystem and registry calls.
Here if you restrict to the Wish, Cmd, and WordVw processes you get an
unexplained stall.
If you remove the filter, you get a haystack again...
How I miss [strace -tt] !
-Alex
MB
>
> > > I've got a program that generates a .csv file which I'd like to open
> > > with Excel.
>
> > > I put together a quick command line demo using tclsh and it worked
> > > perfectly. When I try running it under WISH it takes 30 seconds to
> > > pull up the file.
> > >...
>
>
> starting programs with start in wish much faster. If you don't need
> the output, you could try with [exec .../excel.exe file.csv &]
>
> Mark
Thanks Mark. Adding the '&' made excel start immediately.
I understand that using the '&' should cause the tcl exec command to
return right away, but like you I don't understand why adding '&'
makes the program start faster.
% time {eval exec [auto_execok start] output.csv &}
7000 microseconds per iteration
and excel opens up right away.
So this mystery is cured, but not solved. :)
mb
MB
> > with Excel.
>
> > I put together a quick command line demo using tclsh and it worked
> > perfectly. When I try running it under WISH it takes 30 seconds to
> > pull up the file.
>
> Could you try coding it to run the Excel program directly, just to see what
> happens? Like {exec .../excel.exe file.csv}. When I did that it started
> instantly. It might help identify the problem, and no I don't think it is
> network related.
calling excel directly make the slow startup problem disappear.
I was just hoping to allow the system defined program associated
with .csv files to be used.
Alexandre Ferrieux
Yes, I see the same thing with wordview.exe. After a bit of tracing it
turns out that the sequence is wish->cmd.exe->wordview.exe, (cmd.exe
running the "start" command), and that the stall occurs in the middle
of cmd.exe and is exactly 30 seconds long, down to the millisecond. So
it must be some kind of timeout in failing interprocess communication
or something like that. What's funny is that although it happens long
_before_ wordview is launched, it is still dependent on the nature of
the child (doesn't occur with Acrobat nor Emacs).
Call that an OS...
-Alex