Forum > LCL

[UPDATE] TOpenDialog - 100% CPU - Fan Revs Up

<< < (2/9) > >>


TOpenDialog has no preview but TOpenPictureDialog has.

But anyway - this is bad design.

All filesystem slow down with an amount of more than 10.000 files in one directory  - even ext2/ext3/ext4.

Create some subdirectories and sort the file alphabetical oder numerical.

Or copy your directory to a RAM-disk



There must be something wrong with the OpenDialog:

Reading 30.000 filenames to a stringlist ,takes ~900 ms - not even a second.
Just tested with ext4 on a harddisk. With cleared buffers it is 1200  ms.

So write your own OpenDialog, because there is not much code to improve:

The most is delegated to the widget set.


Well you can "valgrind --tool=callgrind" / kcachegrind it.
Ideally with "--instr-atstart=no".

If you do, do on a folder with less items. Code under valgrind runs a lot slower (like 100 times slower...).

You can then see, if there is any work in the LCL, or if all time is spent in gtk.

I think what is going on is the basic elements shared by file managers and file dialogs jump into some noisy busy housekeeping at each and every opportunity. I see this a lot with "nemo" the file manager. Always updating the counting and indexing of files. Here's a test I did to time the Save and Open dialogs. I move the mouse and pick the file so my "response time" is a factor. I increased the number of frames (jpeg images) from 5000 to 49563 and recorded the time that the dialog was alive (with GetTickCount):

Frames   SaveDialog   OpenDialog
  5000          5 sec            7 sec
10000          4 sec            4 sec
15000          3 sec            4 sec
20000          5 sec            4 sec
25000        10 sec            5 sec
30000        11 sec            8 sec
35000        10 sec          10 sec
40000        11 sec            8 sec
45000        11 sec            8 sec
49563        10 sec            9 sec

Because I used the same directory over and over again, the housekeeping was "up to date" and the lower level processes that freeze up the OpenDialog stayed quiet. That's my theory. I ran "valgrind --tool=callgrind" and looked at it in kcachegrind, but the tiny font in kcachegrind was unusable. I parsed the callgrind.out files with grep but nothing interesting jumped out at me. Thanks for all the responses. I'll keep you posted with any further info / progress.

It seems both SaveDialog and OpenDialog are taking long time. Moreover, OpenDialog seems faster with higher number of images.

Would it be possible to share some hardware specs?
Is this HDD or SSD based folder?
Anti-virus software?


[0] Message Index

[#] Next page

[*] Previous page

Go to full version