lmi
[Top][All Lists]
Advanced

[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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]