On Windows, when starting a Qt GUI "Hello World!" style app, startup time on my 8GB RAM Core i5 2.5-3.2 GHz is dramatically increased when gdb is not built without nls. Doing gdb testapp set verbose on run shows me that the delay is due to symbol loading of QtCore4d (2 vs 6 seconds) and QtGui4d (6 vs 18 seconds). The times are counted by me and recorder visually. The issue is discussed here: http://sourceforge.net/mailarchive/message.php?msg_id=29795741 Where the "rubenvb" build left out --disable-nls and the mingw-builds didn't. I built gdb with --disable-nls seperately and verified it improves the times as described above and in that thread. I'm sure this isn't wanted. Providing a minimal testcase will be difficult, the Qt debug DLL's involved are quite large, but it should be reproducible with the official Qt installer and for example my GCC 4.7.1 32-bit toolchains' gdb.
Does this a 64bit gdb issue or 32bit gdb issue? I read the post: http://sourceforge.net/mailarchive/message.php?msg_id=29795741 They said they were using "mingw64-gcc-4.7.1-2-rubenvb and Mingw-builds-4.7.1 (both 64 bit native) in Qt Creator".
(In reply to comment #1) > Does this a 64bit gdb issue or 32bit gdb issue? > I read the post: > http://sourceforge.net/mailarchive/message.php?msg_id=29795741 > They said they were using "mingw64-gcc-4.7.1-2-rubenvb and Mingw-builds-4.7.1 > (both 64 bit native) in Qt Creator". It is not specific to 64-bit. I just built and tested a 32-bit Qt with my 4.7.2 32-bit toolchain and slow gdb, and startup is about 16 seconds. Switching to a gdb configured with --disable-nls makes that startup time about 6 seconds.
(In reply to comment #2) > Switching to a > gdb configured with --disable-nls makes that startup time about 6 seconds. I saw something similar to this once where a certain .exe was causing gdb to emit millions of calls to complaint. The simplest way to track it down is to do some profiling to see what the problem really is. That may give us some idea of what to do about it.
Created attachment 6659 [details] gprof profile data for GDB with and without nls I attached profile data for gdb without --disable-nls (gdb.txt) and with --disable-nls (gdb-nls.txt). I have verified that under profiling the difference in time between the two versions is present. I built expat/gdb like this: $ ../expat-2.1.0/configure --host=x86_64-w64-mingw32 --prefix=/expat --disable-shared CFLAGS=-pg CXXFLAGS=-pg LDFLAGS=-pg && make && make install $ ../gdb-7.5/configure --host=x86_64-w64-mingw32 --prefix=/gdb --disable-multilib --disable-win32-registry --disable-rpath --disable-werror AR=ar --with-libexpat-prefix=/expat --disable-nls CFLAGS=-pg CXXFLAGS=-pg LDFLAGS=-pg && make && make install $ ../gdb-7.5/configure --host=x86_64-w64-mingw32 --prefix=/gdb-nls --disable-multilib --disable-win32-registry --disable-rpath --disable-werror AR=ar --with-libexpat-prefix=/expat CFLAGS=-pg CXXFLAGS=-pg LDFLAGS=-pg && make && make install If you need anything else, I'll see what I can do.
Something strange is going on, because the profile data says that the two runs took nearly the same time. From gdb-nls.txt: granularity: each sample hit covers 4 byte(s) for 0.08% of 11.99 seconds From gdb.txt: granularity: each sample hit covers 4 byte(s) for 0.09% of 11.70 seconds
We discovered with the new DWARF indexer that strcasecmp is extremely slow on mingw. The new indexer has its own version that is much faster. So, I wonder if that has fixed this problem? It's in GDB 13.