On 06-Aug-2013, at 3:38 AM, 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
I agree. Moving a lot of load from the position filter to a node filter should make things quite faster.
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.
Yes. The multiple runs are however something I think it's okay still take some liberties with for convenience (but very responsibly from now on).
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.
This one - bookmarking - is the most important. There has been some talk of changing the addressing system in the future, but I think the linear addressing we have currently can be completely fine if we start assigning positions for, say, every paragraph. After an edit, perhaps positions occurring after the edit location would need to be transformed - they need not even be recalculated all the time - a list of transforms for subsequent positions could be maintained and lazily recomputed when they need to be accessed. Let's discuss the full implementation in a separate email though. :)
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 :)
Cheers,
Philip
_______________________________________________ WebODF mailing list WebODF@nlnet.nl https://open.nlnet.nl/mailman/listinfo/webodf