You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by scr <r....@consultant.com> on 2007/05/04 15:36:10 UTC
Re: Add Info: Caching DOM and GVT to disk
important additional info:
I updated my app to v1.7beta1.
This accalerates rendering about factor 5!
Same test conditions as before
parsing: 1140..1531
symbols: 125..219
gvt tree: 2047..2515
script binding: 766..2437
rendering: 890..1015ms!!!! (before ~5s)
total: 5500..7218
But script binding is now slower (in my tests)
Is rendering in v1.7 that much faster?
Was script binding modified in v1.7? Can I do any improvements then?
--
View this message in context: http://www.nabble.com/Caching-DOM-and-GVT-to-disk-tf3669525.html#a10322641
Sent from the Batik - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Add Info: Caching DOM and GVT to disk
Posted by scr <r....@consultant.com>.
Hi Tom,
>...run of the garbage collector?
this could propably be true. I did only 4 tests - so average, min or max is
not really representative, but good enough for a rough estimation. even load
from beginning or reload shows differences (I think, because of class
loading)
>Was this on a Mac?
No, WinXP, "ATI Mobility Radeon X1400" graphic board.
I guess, without having a look at the source, your fix mentioned rendering
O*N^2, hits the problem. When we were testing with smaller files = less
elements, performance of v1.6 wasn't that poor. In our experience rendering
(and parsing time, too) increased exponentially -> O*N^2. So, imo, you did a
good job at this point.
If my guess is true, I would propose to mention this fix at v1.7's change
log prominently - to show that batik grows mature handling large amount of
data...
My collegues are satisfied with performance now. So, for more improvements,
imo, we have to optimize the SVG files - I'll discuss that in another
thread, if needed ;)
Thanks for your support.
thomas.deweese wrote:
>
> Hi Rene,
>
> scr <r....@consultant.com> wrote on 05/04/2007 09:36:10 AM:
>
>> I updated my app to v1.7beta1.
>> This accalerates rendering about factor 5!
>
> This is quite surprising to me.
>
>> Same test conditions as before
>> parsing: 1140..1531
>> symbols: 125..219
>> gvt tree: 2047..2515
>> script binding: 766..2437
>> rendering: 890..1015ms!!!! (before ~5s)
>> total: 5500..7218
>>
>> But script binding is now slower (in my tests)
>
> Given the wide swing in script binding
> (3x) It may be that the 2437 figure includes a
> run of the garbage collector.
>
>> Is rendering in v1.7 that much faster?
>
> Was this on a Mac? In V1.7 we switch rendering
> formats based on the OS to obtain the fastest
> rendering. This is the only thing I can think of
> to explain such a large increase.
>
>> Was script binding modified in v1.7? Can I do any improvements then?
>
> There were some changes but I suspect that this
> may be initialization/GC time moving around.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Caching-DOM-and-GVT-to-disk-tf3669525.html#a10410946
Sent from the Batik - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Add Info: Caching DOM and GVT to disk
Posted by th...@kodak.com.
Hi Rene,
scr <r....@consultant.com> wrote on 05/04/2007 09:36:10 AM:
> I updated my app to v1.7beta1.
> This accalerates rendering about factor 5!
This is quite surprising to me.
> Same test conditions as before
> parsing: 1140..1531
> symbols: 125..219
> gvt tree: 2047..2515
> script binding: 766..2437
> rendering: 890..1015ms!!!! (before ~5s)
> total: 5500..7218
>
> But script binding is now slower (in my tests)
Given the wide swing in script binding
(3x) It may be that the 2437 figure includes a
run of the garbage collector.
> Is rendering in v1.7 that much faster?
Was this on a Mac? In V1.7 we switch rendering
formats based on the OS to obtain the fastest
rendering. This is the only thing I can think of
to explain such a large increase.
> Was script binding modified in v1.7? Can I do any improvements then?
There were some changes but I suspect that this
may be initialization/GC time moving around.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org