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 th...@kodak.com on 2007/05/03 12:03:22 UTC
Re: Caching DOM and GVT to disk
Hi Rene,
scr <r....@consultant.com> wrote on 04/30/2007 09:06:23 AM:
> My problem now is just the loading of the files (~7s for about 14.000
> elements), that is the time from opening to the first time user can see
the
> content.
Do you know what the basic breakdown of time is? Parsing XML,
Building GVT tree, Rendering Prep, actual rendering? The
Batik Squiggle Browser can print this out to the console if you
turn on, Edit->Preferences->General->Print debugging information to
console.
> Our goal is to reduce the time < 2s - I'm sure there is a way ;)
> Rendering seems not be a large problem, since elements (static and
dynamic)
> are not very complicated.
>
> Is there a possibility to persist the processed GVT and/or DOM as Java
> Objects to disk and reload it next time? Has anyone tried yet?
Well the best way to persist DOM to disk is as XML ;)
The problem with GVT is that it has some ugly bindings to things
like Fonts that make it complicated to serialize them.
> Is there an alternative to this idea (support by batik API)? Or are
there
> other possibilities to increase performance loading such wired SVG files
> which I may have overseen, yet?
What would a wired SVG file be?
---------------------------------------------------------------------
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
Re: Add Info: Caching DOM and GVT to disk
Posted by scr <r....@consultant.com>.
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: Caching DOM and GVT to disk
Posted by th...@kodak.com.
Hi Rene,
scr <r....@consultant.com> wrote on 05/04/2007 05:33:01 AM:
> > Do you know what the basic breakdown of time is?
> I tried to compare the times as you told me:
>
> * Squiggle (4 runs, startup and reloads)
> load: 1281..1547ms
> building: 1860..3187ms
> preparation: 594..1469(!)
> Rendering: 547..1328
> total(?): 5047..5671ms
>
> What does preparation mean?
This is doing rendering preperation.
Layout of text, bounds calculation, transform
cascading, etc.
> Is total the sum of these times or more?
I think sum is the total time from start of load to
finish of Rendering.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Caching DOM and GVT to disk
Posted by scr <r....@consultant.com>.
Hi Tom,
> Do you know what the basic breakdown of time is?
I tried to compare the times as you told me:
Sample file content is: (unfortunately I cannot optimize it)
<path> elements: 1071
<polyline> elements: 13768
<rect> elements: 634
<line> elements: 0
<polygon> elements: 0
<circle> elements: 0
<ellipse> elements: 390
<text> elements: 257
Overall number of important graphic elements: 16120
nothing else was running on the dual core, 2GHZ, -Xmx512m, JRE1.5.0_11
* Squiggle (4 runs, startup and reloads)
load: 1281..1547ms
building: 1860..3187ms
preparation: 594..1469(!)
Rendering: 547..1328
total(?): 5047..5671ms
What does preparation mean?
Is total the sum of these times or more?
* My Application: (4 runs, startup and reloads)
parsing: 922..1563
symbols: 109..203
gvt tree: 1266..2047
script binding: 448..1391
rendering: 4953..5218
total: 8479..9687
Conclusio:
imo, rendering is the bottle neck, right?
Now I have to investigate what is wrong with rendering.
Do you have any quick hints (was it allready discussed in other forum
threads)?
>The problem with GVT is that it has some ugly bindings to things
>like Fonts that make it complicated to serialize them.
As I recoginzed, serializing the plain Java objects (DOM, GVT) isn't
possible, because some of the used classes are not Serializeable's
(NotSerializableException).
>What would a wired SVG file be?
Sorry, misstyped: should be "weird SVG files".
Thanks
Rene
thomas.deweese wrote:
>
> Hi Rene,
>
> scr <r....@consultant.com> wrote on 04/30/2007 09:06:23 AM:
>
>> My problem now is just the loading of the files (~7s for about 14.000
>> elements), that is the time from opening to the first time user can see
> the
>> content.
>
> Do you know what the basic breakdown of time is? Parsing XML,
> Building GVT tree, Rendering Prep, actual rendering? The
> Batik Squiggle Browser can print this out to the console if you
> turn on, Edit->Preferences->General->Print debugging information to
> console.
>
>
>> Our goal is to reduce the time < 2s - I'm sure there is a way ;)
>> Rendering seems not be a large problem, since elements (static and
> dynamic)
>> are not very complicated.
>>
>> Is there a possibility to persist the processed GVT and/or DOM as Java
>> Objects to disk and reload it next time? Has anyone tried yet?
>
> Well the best way to persist DOM to disk is as XML ;)
> The problem with GVT is that it has some ugly bindings to things
> like Fonts that make it complicated to serialize them.
>
>> Is there an alternative to this idea (support by batik API)? Or are
> there
>> other possibilities to increase performance loading such wired SVG files
>> which I may have overseen, yet?
>
> What would a wired SVG file be?
>
>
> ---------------------------------------------------------------------
> 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#a10319648
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