MantisBT - CMake
View Issue Details
0008292CMakeQtDialogpublic2008-12-14 00:052010-12-14 18:45
Philip Lowman 
Clinton Stimpson 
normalmajoralways
closedfixed 
 
 
0008292: cmake-gui blocks quite a bit while using the keyboard to enter filepaths
The CMake-gui is awesome. My only real gripe about it is that it seems like it goes out to lunch (4 seconds) while trying to fill in any kind of path field via the keyboard, either in a cache variable or in the "Where is the source code", "Where to build the binaries" fields.

What I'm doing is clearing the field (if already filled) and typing in C:\... and immediately after I hit the first key (C) it will block for 3-4 seconds.

CMake CVS, Windows XP SP3
No tags attached.
Issue History
2008-12-14 00:05Philip LowmanNew Issue
2008-12-14 10:16Bill HoffmanStatusnew => assigned
2008-12-14 10:16Bill HoffmanAssigned To => Clinton Stimpson
2008-12-15 23:47Clinton StimpsonNote Added: 0014359
2008-12-16 00:10Philip LowmanNote Added: 0014360
2008-12-16 15:15Clinton StimpsonNote Added: 0014375
2008-12-18 00:38Philip LowmanNote Added: 0014392
2008-12-18 08:51Clinton StimpsonNote Added: 0014394
2008-12-31 13:02Clinton StimpsonNote Added: 0014457
2008-12-31 13:02Clinton StimpsonStatusassigned => resolved
2008-12-31 13:02Clinton StimpsonResolutionopen => fixed
2010-12-14 18:45David ColeNote Added: 0024025
2010-12-14 18:45David ColeStatusresolved => closed

Notes
(0014359)
Clinton Stimpson   
2008-12-15 23:47   
Do you get that pause only with the first letter you type in the field?
(0014360)
Philip Lowman   
2008-12-16 00:10   
No, there are pauses at every folder within the C:. Here are some more observations though.

1. Typing the first letter when nothing is there (the first time) is the absolute slowest (8-seconds on my computer). The CD-ROM spins up while this is happening which may account for some of this time.

2. Afterwords upon initially visiting a new directory it is the slowest presenting the possible choices (of subdirectories). Subsequent visits to that folder within the same cmake-gui.exe run are faster.
(0014375)
Clinton Stimpson   
2008-12-16 15:15   
Can you try this out?

/cvsroot/CMake/CMake/Source/QtDialog/QCMakeWidgets.cxx,v <-- QCMakeWidgets.cxx
new revision: 1.2; previous revision: 1.1
(0014392)
Philip Lowman   
2008-12-18 00:38   
I didn't get any noticeable performance improvement from the patch.

In what is likely a related but more serious issue (and which threw me for a loop yesterday) I have discovered a folder on my hard drive that consistently causes cmake-gui to stall (both with latest CVS and CMake 2.6.2). That folder is my Desktop folder (stall is approximately 45-60 seconds in duration).

There are 12 folders on my Desktop and recursively it contains 4505 Files, 427 Folders, and 58.1GB of data. (probably should tidy things up a bit).

I wish I had more information for you. Is this something that's easily reproducible on your side? Would some random gdb profiling be any help in troubleshooting where the code is stalling? If gdb had came with my MinGW I may have been able to do this tonight as it stands I probably can have a look at it tomorrow if you think it would be of any help.
(0014394)
Clinton Stimpson   
2008-12-18 08:51   
I am able to reproduce some slowness on Windows. For example, with an empty field, and I type 'c' I get a pause of about 2 seconds, but not as bad as you're reporting. When I do it again, it doesn't pause. I don't see this slowness on Linux.

Here's the details of the patch:
With your 0000002 comment above saying if you've visited the directory before, subsequent visits are faster. I took advantage of that and all instances of file completion in the entire cmake-gui now use the same cache. So it should be helping some.

I don't think it should be making your CD-ROM spin like that. I saw an issue in the Qt task-tracker about the floppy drive spinning, and it had been resolved already. What Qt version are you compiling with? Can you see if an upgrade will help.
(0014457)
Clinton Stimpson   
2008-12-31 13:02   
I'm going to assume you were using Qt 4.2, and that upgrading would solve your problem.
(0024025)
David Cole   
2010-12-14 18:45   
Closing bugs that have been resolved for more than 3 months without any further updates.