You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue might be related in some way to the #10 issue.
I'm currently working on a project heavily depending on your library. At the moment, I'm trying to speed up the process and I've noticed with the help of a profiler, that some odfpackage methods are quite slow (not horribly but somewhat a bit). All theses methods are related to the ZipArchiveOutputStream library. I read the code, and at some places, I think i could modify those methods, and uses the java NIO API more, in order to gain some performance.
An example, would be, on the org.odftoolkit.odfdom.pkg.OdfPackage#getBytes method where, instead of using it, but using the Filesystems API (part of NIO) on the Odt document saved on the disk, it would be ten times faster (depending on the ZipEntries size).
Also, all the performance would only benefit files on the disk, and not the one from inputStream, so their would be some branching to do, in order to only use NIO API with Odt backed up by the disk.
What do you think about that? I can help if you want, also I can help with the performances tests, as I have written some on my project.
Regards,
Pierre Lemaigre
The text was updated successfully, but these errors were encountered:
hi Pierre,
i suspect a lot of this IO code was written around 2009 when it had to run on versions of Java that are long obsolete.
if you can measurably improve the performance there, please send PRs.
we could also upgrade the Apache zip library to a newer version, but we don't have any involvement with that project, so if you'd need to do changes there it could cause some delays...
@Pierre-Lemaigre I second what Michael has written, we are grateful for any help!
In addition, performance tests are especially most welcome. I always struggled with those, it worked if the before/after was tested on the same machine, but this did not work with automation... like GitHub regression tests with every commit...
Thanks in advance, Pierre!
Svante
Hi,
This issue might be related in some way to the #10 issue.
I'm currently working on a project heavily depending on your library. At the moment, I'm trying to speed up the process and I've noticed with the help of a profiler, that some odfpackage methods are quite slow (not horribly but somewhat a bit). All theses methods are related to the ZipArchiveOutputStream library. I read the code, and at some places, I think i could modify those methods, and uses the java NIO API more, in order to gain some performance.
An example, would be, on the
org.odftoolkit.odfdom.pkg.OdfPackage#getBytes
method where, instead of using it, but using the Filesystems API (part of NIO) on the Odt document saved on the disk, it would be ten times faster (depending on the ZipEntries size).Also, all the performance would only benefit files on the disk, and not the one from inputStream, so their would be some branching to do, in order to only use NIO API with Odt backed up by the disk.
What do you think about that? I can help if you want, also I can help with the performances tests, as I have written some on my project.
Regards,
Pierre Lemaigre
The text was updated successfully, but these errors were encountered: