omeshwar / svg-android-2

Automatically exported from code.google.com/p/svg-android-2
Apache License 2.0
0 stars 0 forks source link

Parser performance regression from svg-android #20

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
The SVGParser's performance has worsened significantly with svg-android-2 due 
to two-pass parsing.  There are numerous problems with this approach and 
implementation:

 1. The input data source is copied fully into a byte[], resulting in very high GC overhead for large files.
 2. Parsing XML is extremely expensive and should ideally be done only once unless absolutely necessary.
 3. The IDhandler parsing step results in a large number of string-related allocations that increase GC overhead even further.
 4. The added parsing step is used only to support the <use> tag, which is infrequently seen in SVG files (so we're taking a performance penalty for something unlikely to even be used).

Because of these issues (and in particular #4), I propose adjusting this 
feature to only come into effect when the <use> tag is detected.  This would 
result in worsened performance for this case, but greatly improved performance 
for the cases where <use> is not in the file.  One way we can handle this is to 
refactor parse(InputStream, ...) a bit providing a mechanism by which the 
stream can be reopened.  That way, when <use> is detected, the stream is 
reopened if possible, or an exception is thrown if not.  We would also then 
want to propose a new method for SVGParser that can read from a File which is 
quite likely a very common use case.

I can spend some time working on this myself but I need sample input files that 
were used and validated with this feature originally so that I can ensure I 
don't regress the current support for this tag.  Can these be provided in the 
samples/ directory?

Original issue reported on code.google.com by jasta00@gmail.com on 2 Jul 2012 at 8:07

GoogleCodeExporter commented 8 years ago
Actually, we may need to think about this more carefully.  If the <use> tag is 
to be supported, we would ideally transition the whole parser to the DOM model 
which would of course have significant implications for current users of the 
library.  Perhaps support for this tag should be dropped or provided 
unofficially via a compile-time boolean?  Are there any advocates out there 
insisting we keep this support?

Original comment by jasta00@gmail.com on 2 Jul 2012 at 8:56

GoogleCodeExporter commented 8 years ago
Added option to eliminate duplicate pass when creating images

Original comment by suh...@google.com on 7 Nov 2013 at 3:54