Community
Participate
Working Groups
Build 20021119 1. Open PackageExplorerPart.java (with default encoding) 2. Edit -> Encoding -> UTF-16 ==> takes more than a minute, CPU is at 100% 3. Enter some text 4. Select Edit -> Revert ==> takes more than minute, CPU is at 100%
The profiler shows that StyledText's calls to the OS for bidi rendering use the CPU - see attached log (investigated with build I20021127). 1. start empty workspace 2. create simple project 3. create simple file called PackageExplorerPart.java - leave it open in the editor (per default it's the Java editor) 4. in another workspace checkout PackageExplorerPart.java () from CVS (JDT UI plug-in), open it and copy the whole text 5. paste the text into the empty PackageExplorerPart.java 6. Save 7. Set caret to the end of the text 8. Edit -> Encoding -> UTF-16 (big endian) NOTES: 1) UTF-16 alone does not show the problem, but UTF-16 (big endian) and UTF-16 (little endian) do. 2) It matters where the caret is: if its at position 0 then its not that slow but the more you increase the position the slower it gets. For the attatched trace I set the caret to the end of the text - it took minutes. 3) The report does not cover the full operation from above scenario - I stopped after 10 minutes because the operation was still going on 4) On my machine I have bidi and dbcs support installed. The profiler shows that StyledText's calls to the OS for bidi rendering use the CPU - see attached log.
Created attachment 2556 [details] Profiler output 1/2
Created attachment 2557 [details] Profiler output 2/2
Daniel, what was your default encoding? (in step 1 of your first comment). Observed the same problem when starting with my default locale cp1252 on WinXP - had to kill Eclipse after a few minutes. Lynne to investigate and advise.
My default was also cp1252. If you set the cursor at the beginning (e.g. second line) you will not need to kill it ;-)
The problem is that the TextViewer is executing its method getWidthInPixels with the contents of the text viewer up to the caret and the call is being made twice. In my case, my document is approximately 14000 characters long. Putting the caret at the end of the document leads to 28000 calls to StyledText >> getLocationAtOffset (one for each character up to the cursor). Platform calls to measure text are costly and even more so in the bidi case. As you place the caret further down in the document, more text is being measured, so this is why it was faster when the caret is placed at the beginning of the document. Moving to TextViewer. This is not a StyledText issue. The TextViewer should be smarter about measuring text, though I'm not sure why it is even measuring text in the first place. Fixing this problem will speed up the TextViewer in general.
Fixed by Kai. Available in builds > 20021204
