[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] Calculation summary speed
From: |
Greg Chicares |
Subject: |
Re: [lmi] Calculation summary speed |
Date: |
Mon, 30 Oct 2006 22:53:25 +0000 |
User-agent: |
Thunderbird 1.5.0.4 (Windows/20060516) |
On 2006-10-27 16:46 UTC, Greg Chicares wrote:
> On 2006-10-23 14:02 UTC, Greg Chicares wrote:
>> as a test, here are some rough timings (in milliseconds):
>>
>> total calculate prepare format
>> old: 175 150 0 25 no xslt: all C++
>> new: 950 150 300 500 current cvs
>> modified: 430 150 30 250 cvs + patch below
>
> Here are some precise timings--the average of five runs:
>
> total calculate prepare format
> old': 915 158 301 456 before latest change
> new': 549 154 299 96 current cvs
>
> Thus, Evgeniy's changes committed Oct 27 15:52:19 2006 UTC
> yield a tremendous improvement on my machine, in the area
> that most needed more speed.
>
> If the "extremely coarse sketch" snipped from the quoted email
> contains a viable idea, then we have the big win that I was
> hoping for. That "sketch" reduced "prepare" time enormously.
> If we combine the best parts of "modified" and "new'" above:
>
> total calculate prepare format
> modified: 430 150 30 250 "coarse sketch"
> new': 549 154 299 96 xsl optimization
> the winner: 278 152 30 96
>
> then we get 278 milliseconds: quadruple the speed of the
> initial implementation, and only a tenth of a second slower
> than what's in production.
new'': 322 157 20 145 20061030T1836Z cvs
It's fast enough that I can feel the unmetered overhead of
something completely extraneous that I haven't gotten around
to speeding up yet in the MVC Model. IMO it's okay to pay
one hundred fifty ms for the flexibility that's been gained,
and we don't need to make this xml stuff any faster.