User forums > Help

slow

<< < (9/10) > >>

dmoore:
FYI - i managed to get gtk1.2 to compile using the above hacks. however, it:
* is butt ugly :)
* crashes almost immediately even in safemode. (get past the splash screen, cb starts to render then falls over)

from what i observed it is potentially faster, BUT, gtk1.2 doesn't support unicode, so it's not going to be very usable anyway.

rickg22:
The other day i talked to Yiannis about this slow bug. He told me he has never experienced it.  :shock: Any ideas of why it happens on some configs and why not on others?

dmoore:

--- Quote from: rickg22 on August 07, 2007, 11:38:05 pm ---The other day i talked to Yiannis about this slow bug. He told me he has never experienced it.  :shock: Any ideas of why it happens on some configs and why not on others?

--- End quote ---

I think that ultimately, the problem is that linux has to support a whole host of hardware without the support of the hardware manufacturers. Add to this the multiple levels of GUI APIs: X, GTK, wxWidgets, which are all designed to operate slightly differently and its easy to see that small inefficiencies could scale up to massive problems on some hardware.

The proximate cause is probably the windows centric approach of wxWidgets, especially in its approach to drawing and managing windows, result in very inefficient calls to the underlying GUI APIs of non-windows systems. It could also be that wxWidgets linux support just isn't as mature as windows support and future versions will continue to improve in performance.

Personally, I run ubuntu linux 7.04 on a 1.7ghz speedstep laptop, which is my platform of choice for writing code. I've noticed that the GUI of wx apps just don't seem to perform as well as other apps, but I haven't had the same problems that, say, rotalever reported.

I leave as an exercise to the concerned reader writing a GTK native port of CB. there is an easy way to do this, but there isn't room in the margin to explain.  :lol:

Trigve:
Hi *,

I've encountered the same problem on my FreeBSD 6.2 box (In my case the CPU usage was 100% high when using arrows to move cursor form the beginnig to the end of the C++ file)... I've tried to find the bottlenecks causing the slowdown with PMC profiling... As was mentioned here, wxWidgets windows-like desgin has (I think) also some impact on this issue...

So when I was profiling the CB I've found some code blocks that was causing slowdowns (Don't remember everything cause it was 1 - 2 months ago and got only some notes written on the paper).

When I have commented the whole SurfaceImpl::MeasureWidth() in wxscitnilla/src/PlatWX.cpp, the CPU went down from 100 % -> 73% - 76%
Next, when I commented out the LayoutLine() operation in wxscintilla/src/scintilla/src/editor.cxx, usage went down to 63%.

I remember I've drop usage to nearly 10% with commenting some other functions (but editor was merely useless).

The PMC implementation I've used doesn't supported the call graphs...but things has changed and now I'm trying to build FreeBSD 7.0 with PMC with call graphs support added... then I'll try to profile CB again a find something new about the issue.

Trigve

roshi:
Hi there
Nice to see that someone is working on this problem.
I noticed the CPU spike when scrolling since always.
Eats up 50% of both cores of my Dual Core 2GHz T7200
Apparently is something common to wxGTK apps.
Cuse I remember going through all linux available IDEs and at that time I noticed that some other wx based software also had the same problems.
"Native" stuff like IDEs based on gtk alone or based on QT seem to be unaffected...
Sniff sniff.
Too late to change lib so better just improve the one we have.
It really doesn't make sense. It's only scrolling... :)

Navigation

[0] Message Index

[#] Next page

[*] Previous page