Software Woes

Rants, tips and tricks



Sunday, February 17, 2008



GCC isn't that slow after all

I wrote about GCC C++ compiler (g++) before and was really unhappy how slow it is compared to commercial compilers (MS Visual C++ and Borland's C++).

Today I tried building FlameRobin with MSVC Express. It works really nice and it builds FR from scratch in about 2.5 minutes on this machine where I tried it (Intel Celeron M 1.4GHz with 256MB RAM). This in on Windows XP Pro with all anti-virus and similar software turned off.

Then I tried on Linux (it's a dual boot machine) and GCC took 272 seconds, i.e. 4.5 minutes. Both compilers are using PCH. I got really frustrated about this in the past, so much that I considered to install Windows on my machine and do FR development there.

But, I suddenly got the idea that GCC might be losing too much time optimizing. So, I tried to lover the optimization from level 2 to level 1. I got slight improvement: 225 seconds. Still too slow. Then I turned it off, and I got the amazing 130 seconds, i.e. 2:10. This is quite acceptable to development and I guess I'll only use -O2 when we build the release versions from now on.

The option can be changed by setting CXXFLAGS environment variable before you run 'configure' script. Something like this (if your shell is bash):

$ export CXXFLAGS=
$ ../configure ...
$ make

It looks like GCC C++ compiler isn't that bad after all. I won't be switching to Windows any time soon.



Monday, February 11, 2008



Drag and drop Gtk bugs

While working in FlameRobin I often run into DnD bug that locks up the screen completely. Something takes over the mouse input (it's called grab) and the only way is to kill FR. It happen often when DnD is enabled, but also sometimes when it is not.

Looks like we aren't the only ones affected by it. Here are some examples of Evolution team, having the same problem:

http://thomas.apestaart.org/log/?p=502

http://bugzilla.gnome.org/show_bug.cgi?id=365258
http://bugzilla.gnome.org/show_bug.cgi?id=368233

Here's one idea of a fix:

i've found and fixed the bug I reported. The error was here, on gtkhtml.c:

static gint
idle_handler (gpointer data)
{
GtkHTML *html;
HTMLEngine *engine;

+ GDK_THREADS_ENTER ();

...

+ GDK_THREADS_LEAVE ();

return FALSE;
}

idle_handler() was missing surrounding GDK_THREADS_ENTER / _LEAVE calls. Due to
this, idle_handler returned and left the global mutex locked, however it should
have been unlocked because idle_handler was called from the idle loop. As the
mutex was locked, when GTK+ tried to acquire the lock again the thread got
locked (as seen on the previous stack trace).

I just have no idea, where in wxWidgets source do we need to insert those guards.

Also, here's another report:

http://bugzilla.gnome.org/show_bug.cgi?id=351672

Here's interesting comment from that page:

I think Gavin has right. Based on the documentation for signals "drag-drop" and
"drag-data-received", gtk_drag_finish is supposed to be called in one of this
signal handlers to let the source know that the drop is done. Evolution do this
too late, from my point of view, so it breaks this rule and when dragging next
message the call for gtk_drag_finish breaks UI.

It seems vanilla Evolution has fixed it now, although some distro-patched versions still exhibit the problem.