Changes between Version 9 and Version 10 of TEXT_PERFORMANCE_R0

Timestamp:

05/15/10 13:12:59 (15 years ago)

Author:

kyli

Comment:

--

TEXT_PERFORMANCE_R0

@@ -60 +60 @@
 So, the best idea I have is to extract the code of setProcessOptions(..) in a setOptionsInternal(..) method, which takes one more argument: ''shouldProcessText''.
 
-Of course, there is a problem with the manual calling of getProcessed(). It is that I dunno (:) who shall call the method when the change comes outside a client logic (this should be the case with file and server accesses). The problem is very similar to the one in TEXT_SERVER_R0 (the selection does not update in file and server accesses), so I propose to resolve them both in the next week.
+Of course, there is a problem with the manual calling of getProcessed(). It is that I dunno (:) who shall call the method when the change comes outside a client logic (this should be the case with file and server accesses, maybe even "Undo"). The problem is very similar to the one in TEXT_SERVER_R0 (the selection does not update in file and server accesses), so I propose to resolve them both in the next week.
 
 The processors usage seem to be a bit misunderstood by us during the previous task, maybe because of lack of good documentation (my fault). The problem is that the returned TextEffect by the processor's methods should contain the change, which transforms the last processed text to the new result (maybe a picture should be drawn for the implementation, showing the meaning of the changes I will make there). I found out that a wrong change returned caused the large text to cause assertionError in ImmDosTree (Oh, don't ask why) and eventually the "GC overhead limit exceeded". Just a note, since I am not sure why this happens, I cannot be sure that this is the real reason for the GC error. 
@@ -66 +66 @@
 Hm. CaretProcessor, SelectionProcessor and SearchProcessor don't actually need a lot of optimizations - they just apply a style to an interval in the text. I will look again their code, but I doubt that much can be done there. The real problem is with the LinksProcessor, which can be much faster. Maybe the best idea is to use code, similar to the code in CaretProcessor, since it is designed to reuse unaffected intervals in the text. So, nothing special, we get the modified interval, process it again, concatenate it with the rest of the text, and return the result. Bla :)
 
-
+The performance test: [browser:branches/private/kyli/perf/modules/org.sophie2.dev/src/test/java/org/sophie2/dev/author/TextPerformanceSystemTest.java Here].