Why is CB so slow only in Linux?

[Laethnes]

I'm using Code::Blocks 8.02 on Windows and Linux on my laptop, but in Windows is much more faster. Why? Or how can I discover why?

Proc: Intel Pentium dual-core @ 1.6GHz
RAM: 3 GB
HDD: Sata, while copying files about 5 - 20 MB/s (on Windows, I have no idea how faster/slower it is on Linux, because it is not shown to me), it is not full
OS (both actualized):
- Windows XP, SP2
- GNU/Linux Ubuntu 9.10 (so I work on Gnome)

When it is slower on Linux: while doing almost anything; editing text, creating files, opening, closing, opening/closing files, changing projects, scrolling, setting settings, debugging...
When it is faster: maybe while compiling, but when an error occur, it's old slow

I tryied:
- make a clean Ubuntu install
- delete home config folder
- compile newest SVN version (it took a half a day! It was my first Linux compile) (it was few day ago)

In past year, I tried this Linux distributions with same effect:
- Ubuntu 8.04 LTS (Gnome)
- Debian 5 (XFce, Gnome)
- Debian 4 (XFce)
- Debian testing (a few months ago) (XFce, Gnome)

[koso]

It is known problem, with unknown solution

[stahta01]

For C::B slow issues, first turn off code completion plug-in.
Did the problem go away? If yes, the CC is the cause of slow down.

Tim S.

[Laethnes]

It is known problem, with unknown solution

Ou, thanks for answer.

Anyway, how do you resolve this? Or just programming in slow system?

For C::B slow issues, first turn off code completion plug-in.
Did the problem go away? If yes, the CC is the cause of slow down.

Tim S.

I'm not sure, if it is only my psychic expecting faster reaction, but it seem little bit faster. But surely not so fast, as in Windows XP.
GUI things are slow anyway either; opening new file, switching tabs.

[Jenna]

I use it on linux and windows, compile C::B on linux and windows, and there is no real difference in speed.

If compiling takes half a day you have a problem on your system that has nothing to do with C::B.

Compiling with automake-system needs more time than compiling from inside C::B, but that's because of the optimization settings.

[Jenna]

If the gui is slow it can be a graphics driver problem.

By the way I am on debian unstable/experimental 64-bit, with xfce, ati graphics-card and radeonhd-driver.

[dmoore]

... with xfce ...

In my own testing, I've noticed that using xfce instead of gnome/kde *seems* to help. worth investigating further

[Jenna]

... with xfce ...

In my own testing, I've noticed that using xfce instead of gnome/kde *seems* to help. worth investigating further

I used it on lxde and gnome and have C::B installed on another computer under kde (intel graphics) and it is not reasonable slower.
All debian 64-bit.

On my virtual systems, there is also no problem with C::B's performance, except for compiling what takes longer, due to less memory.

[Laethnes]

I use it on linux and windows, compile C::B on linux and windows, and there is no real difference in speed.

If compiling takes half a day you have a problem on your system that has nothing to do with C::B.

Compiling with automake-system needs more time than compiling from inside C::B, but that's because of the optimization settings.

Problem is not compiling. I think compiling inside C::B in Win and Linux are about same speed. Automake systems I do from command line.

If the gui is slow it can be a graphics driver problem.

By the way I am on debian unstable/experimental 64-bit, with xfce, ati graphics-card and radeonhd-driver.

Aha! So that will be it! Because on my OpenGL applications I noticed, that in Linux they are much more slower. On old Ubuntu it was about 25%, now its about 50%, in Debian it was even about 75%. So if I want fast C::B in Linux, I need new laptop, huh? I have Intel integrated graphic card.

Anyway, thanks for replies .

[Jenna]

I have an integrated intel card on my wife's office system (don't know the type at the moment), also debian unstable 64-bit, but with kde4 and C::B and OPenGL-software run fine there.

[Laethnes]

I have an integrated intel card on my wife's office system (don't know the type at the moment), also debian unstable 64-bit, but with kde4 and C::B and OPenGL-software run fine there. (It was running in window mode.)

Maybe I have wrong type (Mobile Intel 965 Express Chipset Family), because my GL application are surely slower. I program them just with SDL and GL, compile them on both systems (so NO Wine) (Windows: mingw, Linux: gcc). Just few polygons, Windows-fps: 170-200, Linux fps: 75-85 (with my very first Ubuntu - it was about 2007 - I hadn't acceleration at all, so 4-5 fps).

... with xfce ...

In my own testing, I've noticed that using xfce instead of gnome/kde *seems* to help. worth investigating further

I used it on lxde and gnome and have C::B installed on another computer under kde (intel graphics) and it is not reasonable slower.
All debian 64-bit.

On my virtual systems, there is also no problem with C::B's performance, except for compiling what takes longer, due to less memory.

To both: yea, I *think* it is little faster on xfce, but difference between gnome/xfce is much more smaller, that between gnome/Windows XP.

Virtual systems: I was thinking about same thing, but I'm not sure, how much great idea is working on Linux, programming on it in Windows in Virtualbox. About memory I have no worries, because I have now 3GB and I use about 1G, so 1G I can assign to virtualbox. But I couldn't use both my processors cores...

[koso]

I have exactly the same problem with the same graphics card on KDE4. This card can hardly run desktop (lags during kwin animations) but most strange is, that one year ago, I used C::B on Gnome without problems. CPU shows 30% activity when moving carret between lines, so it is also huge battery killer.

And programming on Linux .. now I use QTCreator for writing, and C::B for compilation (portable project files are great when developing multiplatform programs), but I hope this problem with C::B will be fixed upstream - in improved intel drivers, which are terrible even in newest development ditribuions.

[Laethnes]

I have exactly the same problem with the same graphics card on KDE4. This card can hardly run desktop (lags during kwin animations) but most strange is, that one year ago, I used C::B on Gnome without problems. CPU shows 30% activity when moving carret between lines, so it is also huge battery killer.

And programming on Linux .. now I use QTCreator for writing, and C::B for compilation (portable project files are great when developing multiplatform programs), but I hope this problem with C::B will be fixed upstream - in improved intel drivers, which are terrible even in newest development ditribuions.

Tell me about it; even if I do not use C::B, on battery, Linux last shorter time, that Windows.
I hope so. In fact how time flows, difference in fps my applications between Win a Linux versions is smaller, so maybe in 2-3 years... (I will have new laptop XD. Maybe.)

[thomas]

I use the build by Jens on Debian testing with Gnome inside VirtualBox (64 Bit Linux running under 32 bit Windows, quite cool), and apart from taking about 3 times longer to start than under Windows XP (dynamic loader, eh?), and the GUI being totally fucked up in respect of usability (this is a Gnome problem though, not Code::Blocks), the IDE works exactly the same as under Windowx XP.
There is no noticeable difference editing, once you have installed a properly usable font, and no difference at all compared to compiling natively with one core and compiling in the virtual machine.

[koso]

So I have tested it now and scrolling in editor seems to be faster (probably wxscintila update). There is only one problem. Everytime matching brackets are shown (when carret is next to opening bracket, both mathing brackets are highlighted), it lags. This happnes for me only on Linux.

I am testing it very easy .. open any sourcode and hold down "down key". Everytime carret is moved on the end of line with "{", it visualy jumps more lines in one moment (=lag).