Bug 46883 - AFP/GOCA: Performance Hot Spot in AbstractGraphicsDrawingOrderContainer.getDataLength()
Summary: AFP/GOCA: Performance Hot Spot in AbstractGraphicsDrawingOrderContainer.getDa...
Status: REOPENED
Alias: None
Product: Fop - Now in Jira
Classification: Unclassified
Component: images (show other bugs)
Version: 0.95
Hardware: All All
: P3 enhancement
Target Milestone: ---
Assignee: fop-dev
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-03-20 03:04 UTC by Jeremias Maerki
Modified: 2012-04-07 01:52 UTC (History)
0 users



Attachments
possible fix (2.64 KB, patch)
2009-07-10 12:42 UTC, Andreas L. Delmelle
Details | Diff
Revised patch (1.91 KB, patch)
2009-08-19 11:53 UTC, Andreas L. Delmelle
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jeremias Maerki 2009-03-20 03:04:33 UTC
I've just stumbled over a serious performance hotspot in the GOCA part when rendering a DataMatrix barcode using Barcode4J. I haven't had time, yet, to investigate if other graphics also exhibit that. Here's some profiling data:

org.apache.fop.afp.goca.AbstractGraphicsDrawingOrderContainer.getDataLength()
Time: 277'609ms (51%)
Own Time: 100'437ms (18%)
Invocation Count: 178'560

GraphicsBox.getDataLength() also seems to be involved here.

Just noting this mostly for myself (to revisit later).
Comment 1 Andreas L. Delmelle 2009-07-10 12:42:58 UTC
Created attachment 23958 [details]
possible fix

Quickly looking at the method in question shows one way of reducing the performance hit: instead of iterating over the collection every time, keep a cached dataLength member, and return that. Haven't tested whether the synchronization overhead outweighs going over the collection repeatedly, though...
Comment 2 Andreas L. Delmelle 2009-07-12 09:42:41 UTC
Note:
Just thought of another way to go about it. Define the dataLength member, and simply update it upon every add() or remove() operation. It will make those operations just a tiny bit slower, but at least it also avoids having to iterate over the entire collection to determine the data length.
Comment 3 Andreas L. Delmelle 2009-08-19 11:53:54 UTC
Created attachment 24151 [details]
Revised patch

Patch in attach attempts at resolving the time spent in the mentioned method by adding dataLength as a member, and increasing/decreasing it with every add or remove operation.
Comment 4 Andreas L. Delmelle 2009-08-23 12:59:41 UTC
Patch applied with rev807010.
Comment 5 Jeremias Maerki 2009-09-28 07:14:41 UTC
I had to revert revision 807010 because it caused a regression. Even very simple SVGs (for example [1]) converted to GOCA caused faulty documents. Due to time pressure, I'm afraid I cannot currently invest more time than I already have on fixing this, so I'm just reverting the change and reopening the bug. Sorry.

http://svn.apache.org/viewvc?rev=819542&view=rev

[1] http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/test/resources/images/img-w-size.svg
Comment 6 Glenn Adams 2012-04-07 01:43:03 UTC
resetting P2 open bugs to P3 pending further review