[IronPython] Beta 4 or build from source?

[Dan Eloff]

On Wed, Sep 3, 2008 at 5:41 PM, Jimmy Schementi
<Jimmy.Schementi at microsoft.com> wrote:
>>
>> It takes 22 seconds from cold, and 16 seconds after that. This is with
>> everything running on localhost.
>>
>> I'm running a Core2 Duo @ 3.6 GHz with 6MB L2 cache, 1600MHz fsb, 6GB
>> 800MHz DDR2, Raid 0 HD.
>>
>> It can get close to a full minute on slower hardware.
>
> HOLY F*#$*$&#^$*&@^#*$@^#!
>
> That's horrrrrrrrrrrrrrible. Like, how big is this app? Or is it just compute intensive? Have you done some poking around to see where the slowness is from? Anything that can be reproduced we'd want to track in our perf lab.
>

No expensive computations at all. Just 100 .py files and only 1 dll
other than DLR/IPY. I've done some "poking around" in the past and
found module importing to be taking over 50% of that time.

I created a script to make timing things in silverlight a little
easier: http://www.ironpython.info/index.php/Profiling

I wish there was a profiler for silverlight...

And then I scattered some milestone() calls around the code. Here's the results:

Loading/ipy startup time takes about ~3 seconds. Here's what happens
with execution of app.py being the reference point of 0 seconds.

* module importing - 4.114

I've started the first and only WebRequest at this point.

* more module importing - 8.834  (note we're up to 50% of the 16 seconds now)
* parse, evaluate, render templates - 10.56
* last python code executes - 11.188

No code left to execute. There's so little to render, and I know how
fast silverlight can render, beats me what is going on here.

Now a full 8.5 seconds after the request was supposedly sent, the
response arrives at 12.525.

* unserializing - 13.356 seconds
* updating interface - 13.564 seconds

Module importing is well known to be a bottleneck. I may take the
unadvised approach of precompiling all .py files with the desktop CLR
and hacking them to change references to Silverlight assemblies in
order to skim some time off this. I can then hack Chiron to re-compile
only changed files. First I think I can optimize some of the imports
to happen later on demand by moving some imports into function bodies,
if I can cut enough off this I won't bother trying to compile them.

The part I find disturbing is the server responds in subsecond time to
the request. Responses come in on a background thread in silverlight
b2, so why the hell does it take 8.5 seconds before anything starts
happening here? I have a whole cpu core sitting idle.

So I did some digging. By 4.114 I've executed BeginGetResponse. But
the request is just queued until silverlight is idle some time after
11.188. Then it is sent and the response comes back subsecond, like
expected. This could cut 15% off the load time if the request could be
sent at anytime in the first 6 seconds after BeginGetResponse. In a
production environment, when it takes many seconds to get a response
from the server, this behavior will really add to the load time.

I don't know what could cause that delay. That's the only request sent
to that port, not even a request for the client access policy (I send
that with cache forever headers).

I'm going to spend this weekend optimizing the hell out of load time
and see what I can achieve. Over the next 6 months of clicking
refresh, I'm sure I'll get the time back :)

-Dan