Changes between Version 5 and Version 6 of NFR_TEXT_PERFORMANCE_R0

Timestamp:

11/10/09 14:46:31 (15 years ago)

Author:

kyli

Comment:

--

NFR_TEXT_PERFORMANCE_R0

@@ -40 +40 @@
 There is a slowdown in large text when creating layout for them. The main reason is that for every line it creates a LineBreakMeasurer. The measurer needs an AttributedCharacterIterator, and it can be created from an AttributedString. The string needs a StringBuilder, which uses all the characters in the text in order to provide an interator for a single line. This is done for every line until the end of the text, for every area. For a text with more than 100 000 chars, this is very slow. The problem can be solved by re-using the attributed string in every sub-text of a given one. It is  the same and does not need to be re-created. The lines are created by using subText(), so a single AttributedString will be made for every change. 
 Another issue is the method HotAreaLayout.splitAreaToLineTexts(). When creating an area layout, the whole text left is given. This method breaks all the text into lines and performs some operations on some of them. It would be better to generate the lines one by one and stop when the area is full. For this purpose, a LineIterator can be created, which will have only one method: nextLine(). It returns the text until the next line break and remembers its new position.
+Creating text, line and segment layouts themselves is actually quite fast. But, the create() method of HotAreaLayout it much more time-consuming. The main reason is the nextLayout() method in LineBreakMeasurer, which takes up to 30-40% of the time needed for creation. Re-using measurers surely lowers the time needed, and it is probably memory effective. So, in TextUtils, modify the createLineBreakMeasurer() so that it uses s QueryCache with the size of 4096 elements (the default size of 1024 is not enough for a text with about 100 pages). The measurer is constructed over a piece of ImmHotText, so its hash can be the same as the resutl of getStyledHash() of that text. Since the measurer remembers its current position, before returning it as a result, the position must be set at the beginning of the string. But there is a problem with this - 2 texts with same content and different positions in their parents will have the same styled hash, but their ACI`s  will have different start indexes. That's why the start index of the ACI generated by a text must always be 0. So, update the ImmHotText.toAci() so that it creates an attributedString of the current text, creates the ACI from it, then creates another attributedString from that ACI (it becomes a subString of the previous) and returns its ACI. The resulting object will have indexes relative to the current text object, not to the parent text. 
+
+Unfortunately, there is no time left to improve overall performance. Instead, some other small changes, which were noticed while looking around the code, will be performed (if the reviewers agree with this):
+ * In HeadTextFrameView, getAreas() could take the areas from an AutoProp areas(). This way, the area list should not be recomputed when the text changes (currently, getAreas() is called by textLayout(), which also tracks the text).
+ * In PwaSelector, the select() methods can be made a bit faster - they can work with only 1 set (currently they have 2).
+ * In SceneHelper.findElementPath, a full DFS is performed every time, even if the element path is found on the 1st iteration. I don't know how much more effective will be putting a return statement, but I think it will not be problematic :)
+
+There is a test case for LBMs caching in the branch ([branches/private/kyli/text/sophie2-platform]), which is [branches/private/kyli/text/sophie2-platform/modules/org.sophie2.base.model.text/src/test/java/org/sophie2/base/model/text/smart/ImmHotTextTest.java  here].
+