I assume we're using arrays to store data for the profiler log - objects
are waaay slower in IE. Also, you'll probably need to close down the
browser completely between each profiler run - in my experience IE leaks
so badly that subsequent runs (even with just the debugger on) can be
very slow.
Henry Minsky wrote:
Anyway, I'm trying to debug why the profiler is acting weird in DHTML in
IE7. I don't get any errors from the
IE script debugger, and boy is it ever slow, but when the profiler
output is analyzed, there's just some stuff that
seems to have gone missing.
I tried an experiment to see what would happen in the profiler if I set
the XMLHTTPRequest.open() call to use
synchronous instead of asynchronous return.
In Firefox on the Mac, the 'chunks' of profiler data from the client to
the server go up in a seemingly random order, closer to the reverse
order of how they are called,
based on the 'seqnum' field. E.g., I see seqnum 10,9,6,5,4,8,7,3,2,1 or
something like that. It's the opposite of what I'd expect. I even tried
setting the Firefox max net connections to
one. Maybe internally the browser doesn't send requests in order that
they are queued. The server reassmbles the into the correct order so it
shouldn't matter anyway, but it still gives bogus results from IE7. I
guess I'll try smaller example case and see if I can
find some problem there.
--
Henry Minsky
Software Architect
[email protected] <mailto:[email protected]>
--
Regards,
Max Carlson
OpenLaszlo.org
