Am Dienstag, 6. August 2013, 01:38:41 schrieb Philip Peitsch:
Hi all,
I'm just putting together a quick plan of what I'll be looking at with regards to performance, to address some queries & requests raised as part of MR#114 (https://gitorious.org/webodf/webodf/merge_requests/114).
As part of this next cycle, my goal is to have editing of a 20 page ODT and flat ODT with images up to a level that is responsive. At the moment, deleting a single character at the end of a sample 11 page document produces an extremely noticable 500ms delay before the character is gone.
From my initial investigation so far my plan of attack for this is: 1. Improve obviously suboptimal paths: OdtDocument * TextPositionFilter - Most of the container checks should be filtered nodes
2. Eliminate the number of times the average run needs to step through the document to find a position: * e.g., upgradeWhiteSpace is called at a specific position. Any Op using this therefore steps through the document up to that specific position usually 2 or 3 times.
3. Implement a bookmark system to quickly retrieve iterators at specific positions within the document. I've used one of these internally for several months now at a different layer above webodf, and have found this to be the most significant improvement.
The plan with each of these is to introduce benchmarking numbers to allow the performance improvements to be proven. As such, I don't plan on addressing any of the performance related concerns in MR#114, as they are literally (from initial profiling checks) drops in a very large ocean of improvement.
If people have other ideas, complaints, etc., as ever, I'm open to anything :)
Sounds good, no complaints at least :) Addressing will be an interesting topic, so fun ahead ;) Cheers Friedrich -- Friedrich W. H. Kossebau // KO GmbH http://kogmbh.com/legal/