#35 FAR Colorer uses 30-50% CPU in the idle mode
FAR colorer in editor uses uses 30-50% of CPU time in the idle mode.
Steps to reproduce:
1) Make sure the Colorer plugin is installed.
2) Start FAR.
3) Open the large text file in the editor.
I used the following file:
"C:\Program Files\Microsoft Visual Studio 8\Microsoft Visual Studio 2005 Standard Edition - ENU\Logs\VSMsiLog44F2.txt"
File size: 71,992,788 bytes
4) Wait until the file is fully loaded into the editor (with color highlighting). Do not edit the file.
5) Start the Task Manager and monitor the CPU usage of the FAR instance.
Actual Result
CPU usage is from 30% to 50%.
Expected Result
CPU usage is 0% to 1%.
Analysis
The sequence of calls that causes the problem is the following:
1. Manager::ProcessMainLoop()
2. Manager::ProcessKey(key=KEY_IDLE)
3. FileEditor::ProcessKey(key=KEY_IDLE)
4. FileEditor::ReProcessKey()
5. FileEditor::ProcessEditorInput()
6. PluginManager::ProcessEditorInput()
As a result the KEY_IDLE is processed by every editor's plugin. In case of the "Colorer" plugin this causes the update of the text highlighting in the editor, which takes a great amount of CPU time in the idle mode.
For more information see the following link:
http://bugs.farmanager.com/view.php?id=496
Logged In: YES
user_id=313042
Originator: NO
Thats kind of normal behaviour. Colorer tries to parse the file ahead in the background.
It uses KEY_IDLE event for this.
On regular files to edit this works quite good. The problem is with huge files where this logic is kind of useless.
Logged In: NO
> Thats kind of normal behavior. Colorer tries to parse the file ahead in
> the background. It uses KEY_IDLE event for this.
Just to investigate this problem I tried to disable sending KEY_IDLE to all plugins in the FileEditor::ProcessKey(key=KEY_IDLE) (FAR 1.80). The colorer in the FAR editor worked just fine. I got the syntax highlighting and the CPU usage was about 0%. It worked on both small and large files.
Is it really necessary to use KEY_IDLE in the colorer? If it is, could you adjust a logic so it will not use CPU as aggressively in the idle mode?
Currently it's really hard to tell because there is no sources for the colorer plugin for the FAR Manager. Could you post sources for this plugin to SourceForge?
Logged In: YES
user_id=313042
Originator: NO
Surely it'll work fine. The background parse feature parser the file "ahead".
Therefore, with this feature disabled you'll have to wait alittle if you jump to the eof.
Agree, it may be turned to work better, however thats difficult - too many usecases and too many different situations to deal with (some use big, some use small, some just browse, others modify...).
The sources are in /colorer/src/pcolorer
see FarEditor::editorInput
Logged In: YES
user_id=313042
Originator: NO
Moving it to feature requests.
Probably better "guessing" logic could be used to determine, is it required to initiate 'parse ahead'.