search

andreikop / enki

A text editor for programmers
http://enki-editor.org
GNU General Public License v2.0
161 stars 38 forks source link

Excessive CPU usage while scrolling #87

Closed andreikop closed 11 years ago

andreikop commented 11 years ago
  1. Opening the same C file, placed cursor at top, holding "Down" button (so cursor is moving down and the text scrolling). Old enki: about 60% CPU usage; Qutepart enki: about 90% CPU usage. Which CPU? 50 % on my 5+ year old Core 2 Duo
andreikop commented 11 years ago

Which CPU? When was it produced?

vi commented 11 years ago

Intel Atom N550 @ 1.50GHz.

I'm not saying that new Enki is too slow at scrolling (90% Enki + 10% Xorg, but scrolling look smooth), but it worth to know that this operation is about 1.5 times more CPU-hungry compared to old Enki.

If you program does run on a 64MB 300Mhz computer (slow, but usable), it should run well on a modern computer. If it just can't be run (or way too slow) on old hardware then it is expected to be mediocre on a modern computer. Even if users' computers have X memory and Y CPU, it does not mean that you (an application programmer) shall expect and test on X memory and Y CPU (at least for text editors), because of on a modern hardware I expect text editor to be just one of the applications and expect it to be fast even when there is background compilation running + some heavy memory-hungry database shuffling its tables + something downloading from net (disk IO filled up) + ....

andreikop commented 11 years ago

Highlighting is slower here, because

  1. highlighting is done in interpreted language ( + C extension)
  2. highlighter itself interprets XML files. So, we have 2 interpretations

QScintilla has 0 intepretations, it is quicker. But it

  1. doesn't grow in functionality
  2. don't have so many parsers. (i.e. Closure)

So, I think performance degradation is reasonable trade-off. While performance is still good on modern (widelly used) PCs Enki is planed a text editor for coding, not a tiny tool, which you might use on embedded system to fix configs

vi commented 11 years ago

highlighter itself interprets XML files.

Each redraw?

Highlighing (especially some advanced kind of) should be in background, not interfering with usual plain straightforward way. Is it much more inconvenient to first (or if highlighting is not finished by some N00 millisecond deadline) show unhighlighted text, then change it to highlighted when highlighting is done.

andreikop commented 11 years ago

It was general info about bugs connected with CPU usage, startup, memory

Qutepart