On Wed, Sep 3, 2008 at 5:41 PM, Jimmy Schementi <[EMAIL PROTECTED]> 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*#$*$&#^$*&@[EMAIL PROTECTED] > > 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 _______________________________________________ Users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
