Hello,
I found Geany some time ago, searching for a simple, small IDE, and while it definitely looks very nice, the thing that surprised me the most was how incredibly slow the editor was. I tried many different editors before, and while GTK+ based ones have always been slower than others, with higher CPU overhead, I've never seen anything as slow as Geany (and SciTE, to be fair) - for example, in a C++ file, holding the left/right keys (so the cursor keeps going to left/right) consumes over 50% of CPU and it even stutters, stumbles on brackets, holding the up/down keys is even more CPU intensive, the editor actually cannot keep up with the cursor movement, the same with scrolling (which is slow and laggy - the scrollbar cannot update itself fast enough, it jumps instead of moving continuously), and also mouse selection - when I select a larger part of the source code, like a function with 20+ lines, CPU usage goes to 100% and the selection lags, too, it cannot keep up with the mouse movement. In a plain text file (with no syntax highlighting), the CPU usage is naturally lower, it does not lag so much. The extremely slow editor also affects the main menu redrawing performance - when a blank file is open in the editor, the menu can redraw as fast as in any other GTK+ app (i.e. fast enough), with a plain text file, it's slower, but when a .cpp file is loaded, again the redrawing is extremely slow, the menu cannot keep up with the mouse (when I ride through the menu from left to right, for example).
Now, I know it sounds as if my computer is broken, but when I compare it with other editors: for example in emacs, the CPU usage while holding the arrow keys is about 0% (even in the GTK+ version), other, more modern and heavyweight editors like the Kate-based ones (KDE) consume about 2-3 times less CPU cycles than Geany does for these basic tasks like selection, typing and scrolling, the same applies even to the gedit editor in GNOME, with its syntax higlighting - even though it's GTK+ based, there are no lags and 100% CPU usage at all.
Is there anything that can be done about it? Or is it just my computer? It's a 2.4 GHz P4 with the nv driver for X.org, tried it on Debian and Arch Linux, which are both pretty lightweight to begin with... Is the Scintilla library really so inefficient? Because like I said, the only other editor I've tried that's as slow as Geany was SciTE, so it looks like it's Scintilla's fault...
On Thu, 4 Dec 2008 01:35:25 +0100, Jakub Misak jmisak@centrum.cz wrote:
Hello,
I found Geany some time ago, searching for a simple, small IDE, and while it definitely looks very nice, the thing that surprised me the most was how incredibly slow the editor was.
Somehow I din't notice the slowness, but scrolling a document in Geany consumes a full 100% CPU (one core) here while scrolling a document (with images) in OpenOffice.org only takes ~40% of one core.
I did not check Scite's performance yet...
-H-
(Xubuntu 8.10 / AMD Athlon(tm) 64 X2 Dual Core Processor 4400+)
Am Donnerstag, den 04.12.2008, 12:22 +0100 schrieb Harold Aling:
On Thu, 4 Dec 2008 01:35:25 +0100, Jakub Misak jmisak@centrum.cz wrote:
Hello,
I found Geany some time ago, searching for a simple, small IDE, and while it definitely looks very nice, the thing that surprised me the most was how incredibly slow the editor was.
Somehow I din't notice the slowness, but scrolling a document in Geany consumes a full 100% CPU (one core) here while scrolling a document (with images) in OpenOffice.org only takes ~40% of one core.
I can confirm, that scrolling gets "slower" or "stucking" and CPU gets 100% here to. This especially seem to happen, when there is text outside the "drawed" area of the editor component and has to be redrawn.
I also noticed the cursor "stucking" around braces when moving it with the arrow keys. I can't say this would be slowing down the work, but it's getting more slower if the CPU has some other things to do. So i can imagine, if someone has a very slow CPU - say an old 233MHz engine - this would not be that nice.
I did not check Scite's performance yet...
Unfortunately i don't have Scite installed here too...
Regards, Dominic
On Thu, 04 Dec 2008 13:48:33 +0100 Dominic Hopf dmaphy@googlemail.com wrote:
I also noticed the cursor "stucking" around braces when moving it with the arrow keys. I can't say this would be slowing down the work, but it's getting more slower if the CPU has some other things to do. So i can imagine, if someone has a very slow CPU - say an old 233MHz engine - this would not be that nice.
I mainly use a 233MHz machine and never really have trouble with it, but I don't hold down the arrow keys ever. The scrollbar can be a bit jerky sometimes, but still quite usable. I tend to use the mouse scroll wheel and page up/down. But, I have quite a lot of memory, 320900 kB (MemTotal with /proc/meminfo) and have disabled unnecessary processes, and run Xfce.
The only thing that really slows down the system that I do is running the autotools through Geany ;-)
Regards, Nick
On Thu, 04 Dec 2008 13:48:33 +0100 Dominic Hopf dmaphy@googlemail.com wrote:
I also noticed the cursor "stucking" around braces when moving it with the arrow keys.
Should be fixed now in current SVN - by delaying brace highlighting by 100ms.
Regards, Nick
On 07/10/2009 07:07 AM, Nick Treleaven wrote:
On Thu, 04 Dec 2008 13:48:33 +0100 Dominic Hopfdmaphy@googlemail.com wrote:
I also noticed the cursor "stucking" around braces when moving it with the arrow keys.
Should be fixed now in current SVN - by delaying brace highlighting by 100ms.
The delay can be felt, but I suppose it's better to feel that the arrow keys are more responsive than the brace highlighting.
On 07/10/2009 07:07 AM, Nick Treleaven wrote:
On Thu, 04 Dec 2008 13:48:33 +0100 Dominic Hopfdmaphy@googlemail.com wrote:
I also noticed the cursor "stucking" around braces when moving it with the arrow keys.
Should be fixed now in current SVN - by delaying brace highlighting by 100ms.
After using this for some time, I noticed a small annoyance associated with the new delay;
If you type two braces {} with brace highlighting enabled, and then begin typing characters between them, you will eventually see the last character (before the closing brace) highlighted red, instead of the brace itself getting highlighted.
Is it possible to cancel or restart the delay timer while keys are being pressed (or while characters are being inserted)?
On Fri, 10 Jul 2009 12:26:40 -0700 Jason Oster parasyte@kodewerx.org wrote:
Should be fixed now in current SVN - by delaying brace highlighting by 100ms.
After using this for some time, I noticed a small annoyance associated with the new delay;
If you type two braces {} with brace highlighting enabled, and then begin typing characters between them, you will eventually see the last character (before the closing brace) highlighted red, instead of the brace itself getting highlighted.
Thanks for reporting. Should be fixed now.
Regards, Nick
On 07/14/2009 03:33 AM, Nick Treleaven wrote:
On Fri, 10 Jul 2009 12:26:40 -0700 Jason Osterparasyte@kodewerx.org wrote:
After using this for some time, I noticed a small annoyance associated with the new delay;
If you type two braces {} with brace highlighting enabled, and then begin typing characters between them, you will eventually see the last character (before the closing brace) highlighted red, instead of the brace itself getting highlighted.
Thanks for reporting. Should be fixed now.
Looks good here. Thanks Nick.
Am Donnerstag, den 04.12.2008, 12:22 +0100 schrieb Harold Aling:
On Thu, 4 Dec 2008 01:35:25 +0100, Jakub Misak jmisak@centrum.cz wrote:
Hello,
I found Geany some time ago, searching for a simple, small IDE, and while it definitely looks very nice, the thing that surprised me the most was how incredibly slow the editor was.
Somehow I din't notice the slowness, but scrolling a document in Geany consumes a full 100% CPU (one core) here while scrolling a document (with images) in OpenOffice.org only takes ~40% of one core.
I just checked this scrolling behaviour with some other programs: OpenOffice 3: very small CPU load scribes (using gtksourceview): very high cpu load gedit (also using gtksourceview): very high cpu load
Not sure if this is useful or interesting for someone.
Well, i forgot to mention my system: AMD Duron with 1800MHz, 1G RAM
Regards, Dominic
On Thu, 4 Dec 2008 01:35:25 +0100 Jakub Misak jmisak@centrum.cz wrote:
Is the Scintilla library really so inefficient? Because like I said, the only other editor I've tried that's as slow as Geany was SciTE, so it looks like it's Scintilla's fault...
There are a few things Geany does which makes scrolling slower, like trying to parse the current scope - although I did some optimization on that a while ago.
It might be partly how Scintilla is setup - can you try changing the following SciTE settings and see if there are performance improvements:
buffered.draw=1 #two.phase.draw=0
Probably these would be fastest set like this:
buffered.draw=0 two.phase.draw=0
If flickering is bad, try:
buffered.draw=1 two.phase.draw=0
If this helps, we could add prefs for these settings in Geany.
Regards, Nick
On Thu, 4 Dec 2008 12:58:07 +0000 Nick Treleaven nick.treleaven@btinternet.com wrote:
It might be partly how Scintilla is setup - can you try changing the following SciTE settings and see if there are performance improvements:
buffered.draw=1 #two.phase.draw=0
Probably these would be fastest set like this:
buffered.draw=0 two.phase.draw=0
If flickering is bad, try:
buffered.draw=1 two.phase.draw=0
If this helps, we could add prefs for these settings in Geany.
Thanks for the tip. Unfortunately, it does not make it any faster...
On Thu, 4 Dec 2008 01:35:25 +0100, Jakub Misak jmisak@centrum.cz wrote:
Hello,
I found Geany some time ago, searching for a simple, small IDE, and while it definitely looks very nice, the thing that surprised me the most was how incredibly slow the editor was. I tried many different editors before, and while GTK+ based ones have always been slower than others, with higher CPU overhead, I've never seen anything as slow as Geany (and SciTE, to be fair) - for example, in a C++ file, holding the left/right keys (so the cursor keeps going to left/right) consumes over 50% of CPU and it even stutters, stumbles on brackets, holding the up/down keys is even more CPU intensive, the editor actually cannot keep up with the cursor movement, the same with
I never experienced such heavy problems with just moving the cursor. I must admit, I'm mostly working on my desktop, an Athlon 64 X2 4600+. But I can't remember noticing such behaviour with my laptop (1.5GHz Celeron) nor with my old desktop (1.8 GHz Athlon single-core, IIRC).
scrolling (which is slow and laggy - the scrollbar cannot update itself fast enough, it jumps instead of moving continuously), and also
Yeah, that is Scintilla. It is known that Scintilla performs not that good on scrolling. It was reported several times to Scintilla but Neil, the developer stated that it is not is highest priority to work on this. Feel free to fix the code, make things better and ideally provide a patch. It's open-source.
it does not lag so much. The extremely slow editor also affects the main menu redrawing performance - when a blank file is open in the editor, the menu can redraw as fast as in any other GTK+ app (i.e. fast enough), with a plain text file, it's slower, but when a .cpp file is loaded, again the redrawing is extremely slow, the menu cannot keep up with the mouse (when I ride through the menu from left to right, for example).
This is almost completely independent from Geany, the menu is drawn by GTK. Except for a few callbacks which are ran when a submenu is opened, Geany itself isn't involved there.
Now, I know it sounds as if my computer is broken, but when I compare it with other editors: for example in emacs, the CPU usage while holding the arrow keys is about 0% (even in the GTK+ version), other,
Never ever compare Geany with emacs. Also the GTK version of emacs is in no way comparable. The editing widget of emacs is not based on GTK whereas Scintilla is.
more modern and heavyweight editors like the Kate-based ones (KDE) consume about 2-3 times less CPU cycles than Geany does for these basic
This is again incomparable because KDE != GTK.
tasks like selection, typing and scrolling, the same applies even to the gedit editor in GNOME, with its syntax higlighting - even though it's GTK+ based, there are no lags and 100% CPU usage at all.
Is there anything that can be done about it? Or is it just my computer? It's a 2.4 GHz P4 with the nv driver for X.org, tried it on Debian and Arch Linux, which are both pretty lightweight to begin with... Is the
Same here. I'm using Debian since years, switched lately to ArchLinux for a few months but finally back to Debian. Except for the known scrolling performance issue, I'm afraid to not know what's the problem. Of course, Geany is not as fast as emacs, no doubt on that. But your described behaviour when switching between menus, is really GTK. But your system should be fast enough to not cover such issues, IMO.
Regards, Enrico
Personally, I see that a lot of people are using the nv driver and expereincing slow gtk performance. Unless I am mistaken, and I'm fairly cerain I'm not, this can be explained and is NOT A COINCIDENCE. My apppologies to those of you using nvidia who will ultimately agree with this.
Firstly: The NV driver is non-accelerated, which means that it is able to use the full capabilies of the card (frequency, height, width, etc), however is does so at the most basic level imaginable, the nv driver *allows* function. GTK on the other hand, IS accelerated, or rather is designed to be, and relies IIRC on XLibMesa. IIRC, that means that when an activity (like scrolling) is activated, it's going to use 100% CPU becuase CPU's aren't optimized for graphics processing (It generates a lot of flops). Conversly, using 'nvidia' AND minimal Effects (Enables GLX) WILL reduce the CPU load for scrolling, depending on your graphics processor. At some level, a slower GPU WILL cause scrolling to lag/jump, but less-so than using a processor for the same operation.
Secondly: People seem to always want to compare apples to oranges. this has already been covered, GNOME/GTK !+ KDE/Qt, Scintilla != Emacs/Vim. Perhaps a more inteligent argument would be to use vi/vim as the editor instead of scintilla. If this is what you want, you probably don't want geany.
Sixth & Lastly: Complaning about performance (that is the idea of this thread, no?) seems silly to me. When one uses a software product so defined by choice, one should function within the bounds of that aim, eh? If this application (geany) doesn't meet your needs, then find a better solution. If this is the best solution for you, then, I'm not sure why you're making the complaint.
Thirdly: If you are largely offended by the above, and feel that my commentary is offtopic or out of line, please consider me ignorant and rude, as you probably already have. It remains that if you considered this a bug, you would have posted it as such, but rather than doing so, you have made it a topic of discussion, and I largely respond by saying that geany is NOT slow, nor are scrolling or any other operation slow. IMO, especially as compared to Industry standards such as ecliplse, visual studio, etc, geany is quite quick, especially where it counts. I have selected geany over those, based almost entirely on speed and features.
On Thu, Dec 4, 2008 at 8:33 AM, Enrico Tröger enrico.troeger@uvena.dewrote:
On Thu, 4 Dec 2008 01:35:25 +0100, Jakub Misak jmisak@centrum.cz wrote:
Hello,
I found Geany some time ago, searching for a simple, small IDE, and while it definitely looks very nice, the thing that surprised me the most was how incredibly slow the editor was. I tried many different editors before, and while GTK+ based ones have always been slower than others, with higher CPU overhead, I've never seen anything as slow as Geany (and SciTE, to be fair) - for example, in a C++ file, holding the left/right keys (so the cursor keeps going to left/right) consumes over 50% of CPU and it even stutters, stumbles on brackets, holding the up/down keys is even more CPU intensive, the editor actually cannot keep up with the cursor movement, the same with
I never experienced such heavy problems with just moving the cursor. I must admit, I'm mostly working on my desktop, an Athlon 64 X2 4600+. But I can't remember noticing such behaviour with my laptop (1.5GHz Celeron) nor with my old desktop (1.8 GHz Athlon single-core, IIRC).
scrolling (which is slow and laggy - the scrollbar cannot update itself fast enough, it jumps instead of moving continuously), and also
Yeah, that is Scintilla. It is known that Scintilla performs not that good on scrolling. It was reported several times to Scintilla but Neil, the developer stated that it is not is highest priority to work on this. Feel free to fix the code, make things better and ideally provide a patch. It's open-source.
it does not lag so much. The extremely slow editor also affects the main menu redrawing performance - when a blank file is open in the editor, the menu can redraw as fast as in any other GTK+ app (i.e. fast enough), with a plain text file, it's slower, but when a .cpp file is loaded, again the redrawing is extremely slow, the menu cannot keep up with the mouse (when I ride through the menu from left to right, for example).
This is almost completely independent from Geany, the menu is drawn by GTK. Except for a few callbacks which are ran when a submenu is opened, Geany itself isn't involved there.
Now, I know it sounds as if my computer is broken, but when I compare it with other editors: for example in emacs, the CPU usage while holding the arrow keys is about 0% (even in the GTK+ version), other,
Never ever compare Geany with emacs. Also the GTK version of emacs is in no way comparable. The editing widget of emacs is not based on GTK whereas Scintilla is.
more modern and heavyweight editors like the Kate-based ones (KDE) consume about 2-3 times less CPU cycles than Geany does for these basic
This is again incomparable because KDE != GTK.
tasks like selection, typing and scrolling, the same applies even to the gedit editor in GNOME, with its syntax higlighting - even though it's GTK+ based, there are no lags and 100% CPU usage at all.
Is there anything that can be done about it? Or is it just my computer? It's a 2.4 GHz P4 with the nv driver for X.org, tried it on Debian and Arch Linux, which are both pretty lightweight to begin with... Is the
Same here. I'm using Debian since years, switched lately to ArchLinux for a few months but finally back to Debian. Except for the known scrolling performance issue, I'm afraid to not know what's the problem. Of course, Geany is not as fast as emacs, no doubt on that. But your described behaviour when switching between menus, is really GTK. But your system should be fast enough to not cover such issues, IMO.
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Personally, I see that a lot of people are using the nv driver and expereincing slow gtk performance. Unless I am mistaken, and I'm fairly cerain I'm not, this can be explained and is NOT A COINCIDENCE.
The binary "nvidia" driver makes no perceptible difference whatsoever.
Firstly: The NV driver is non-accelerated
No, it's not. It is a 2D driver supporting 2D acceleration. The binary driver also offers 3D acceleration, (broken) XRender "acceleration" and things like that.
GTK on the other hand, IS accelerated, or rather is designed to be, and relies IIRC on XLibMesa.
It has nothing to do with XLibMesa. If anything, working XRender acceleration may help, as well as using compositing, but I really doubt it would help too much in things like moving the cursor and stumbling on a matching pair of braces.
(like scrolling) is activated, it's going to use 100% CPU becuase CPU's aren't optimized for graphics processing (It generates a lot of flops).
Geany and SciTE are definitely the only two GTK+ applications I've tried using 100% CPU for scrolling. And I've been using many GTK+ 2.x applications for many years, on Linux, BSD and Windows. GTK+ is slow everywhere, with any driver and any graphics card on any OS, which has been a well-known problem for many years (with tons of endless discussions and no conclusions). But it's not *that* slow. Scrolling in GTK+ definitely does not need 100% CPU with the nv driver.
Secondly: People seem to always want to compare apples to oranges. this has already been covered, GNOME/GTK !+ KDE/Qt, Scintilla != Emacs/Vim.
Comparing Geany with the KDE-based editors is completely fair, interesting and reasonable. What you're saying is equivalent to "you cannot compare the Linux and FreeBSD kernel performance, because they're two different kernels!", or "you cannot compare the rendering speed of various web browser engines (Gecko, WebKit etc.), because they're different rendering engines!"
Of course that's the whole point of performance comparisons - comparing different products. And that's why such comparisons are so popular and made so often on various websites. If a KDE based editor can do the same things with 50% less CPU usage than its GTK+ counterpart, then it's interesting to ask why.
Sixth & Lastly: Complaning about performance (that is the idea of this thread, no?) seems silly to me. When one uses a software product so defined by choice, one should function within the bounds of that aim, eh?
Firstly, I was not complaining, I was asking. Secondly, I don't know what world you're living in, but in my world, mentioning a deficiency in a product I use is perfectly legitimate and normal. When someone spots a weak point in something he's using, it is actually desirable to talk about it, in both commercial and free software communities. Progress is the thing that's turning the world around. "Silently accepting the flaws in everything I use" will never lead to anything, it just conserves the current status quo forever. The earth stops spinning.
If this application (geany) doesn't meet your needs, then find a better solution. If this is the best solution for you, then, I'm not sure why you're making the complaint.
See above.
Thirdly: If you are largely offended by the above, and feel that my commentary is offtopic or out of line, please consider me ignorant and rude, as you probably already have.
What actually bothers me is that you don't know what you're talking about (see the graphics driver stuff), then you're teaching me nonsense based on these mistakes, and then you're telling me that I have no right to complain about anything.
So while I accept your right to reply to my post (that's why I'm posting it to a public mailing list), next time I would prefer if you did so only if you really had something to say. Thank you.
For what it's worth, I use Windows a lot and Linux almost never. I don't watch CPU usage that closely, but for me, SciTE and Geany are quite fast. I especially like SciTE because I don't normally use IDE-like features anyway and SciTE has always been small and fast on even the wimpiest Windows machine. The times that I've used Geany, it felt fine to me.
The point of my reply is simply that if there are problems with Scintilla, SciTE, or Geany, my guess is that they are absent or not as severe on Windows.
John
On Fri, 5 Dec 2008 00:40:45 -0500 "John Yeung" gallium.arsenide@gmail.com wrote:
For what it's worth, I use Windows a lot and Linux almost never. I don't watch CPU usage that closely, but for me, SciTE and Geany are quite fast. I especially like SciTE because I don't normally use IDE-like features anyway and SciTE has always been small and fast on even the wimpiest Windows machine. The times that I've used Geany, it felt fine to me.
The point of my reply is simply that if there are problems with Scintilla, SciTE, or Geany, my guess is that they are absent or not as severe on Windows.
Thanks for the observation - I haven't tried Geany or SciTE on Windows, but generally, GUI on MS Windows is denifitely much faster than GUIs on top of the X Window System, and even though in my experience GTK+ on Windows is a lot slower than the native Windows GUI, it stil feels faster than GTK+ on Linux or BSD. So I'll try running Geany on Windows later and see if it makes a difference...