Checking run time characteristics for QFileDialog::getOpenFileName()

aha_1980

@elfring just to add to @SGaist, especially check network drives. I especially have a delay in Windows because of that (but only some seconds).

elfring

@SGaist said in Checking run time characteristics for QFileDialog::getOpenFileName():

What desktop environment are you using ?

I am using XFCE 4.12.1 primarily at the moment while I have got access also to programs from other environments.

How many and what type of storage system do you have connected to your computer ?

I refer to directories from a local hard disk for this clarification request.

SGaist

The fact that you are opening the dialog on your local hard drive, doesn't mean that there's no access to the other devices that you may have.

By the way, do you have the same problem if your disable the native dialog ?

elfring

The fact that you are opening the dialog on your local hard drive, doesn't mean that there's no access to the other devices that you may have.

I would be also curious then which of other possible device connections will influence the primary file selection in undesirable ways.
Which data processing actions can disturb the dialogue display considerably?

By the way, do you have the same problem if your disable the native dialog ?

Can be determined if a native file dialogue is used by the function “QFileDialog::getOpenFileName” at all (if the passing of the configuration option “QFileDialog::DontUseNativeDialog” was omitted so far)?
(Do I need to add debug output to any source code place?)

JonB

@elfring

Don't know what you're saying, but @SGaist is suggesting you try passing the DontUseNativeDialog flag and see whether Qt's own inbuilt dialog behaves better for you in this situation.
While you're at it. The most likely cause for any big time delay would be the dialog doing any work examining network or detachable-media drives. Note that Qt has a QFileDialog::DontUseCustomDirectoryIcons flag, which you should also try using:

Some platforms allow the user to set a different icon. Custom icon lookup cause a big performance impact over network or removable drives.

And on that note what do you pass as the "initial/root directory" to your getOpenFileName()? Try not to pass the very "root" directory of the file system, where network/removable drives stem from, if you don't need to. Pass a directory lower down on a fixed, local drive if you can.
Finally, if you still have big delays and don't know why, use Linux strace to discover what the code is actually doing behind the scenes to cause this!

elfring

Finally, if you still have big delays and don't know why,

I am wondering about occasional hiccups in the responsiveness of file management dialogues.

use Linux strace to discover what the code is actually doing behind the scenes to cause this!

I have got the impression that it can matter also which program tries to open a fresh dialogue for another file (or directory) selection. If there is an unpleasant software initialisation process involved, I imagine that it can become very challenging to find the concrete error reason in a reasonable time frame.
Will any other debugging aproaches or system performance analysis help better?

JonB

@elfring

Will any other debugging aproaches or system performance analysis help better?

Yes, like I said, use strace!

elfring

Yes, like I said, use strace!

I have accidentally noticed the unpleasant software behaviour once more.

The program trace displays so many information so that it seems to be hard to connect another unexpected big delay in the file directory display with a specific function call within the affected software implementation.

JonB

@elfring
Well I can't see your output so I don't know. But I would have expected that provided you are looking at the strace output in real time what you would see is the last line of output would "hang" just as you went into a "delay", and that would be your indication as to why....

elfring

you are looking at the strace output in real time

Not really. - I would start such program tracing only after a personal delay to notice that data processing for the function “QFileDialog::getOpenFileName” might take longer than what I would usually expect.
(I might be more patient under other circumstances.)

what you would see is the last line of output would "hang"

This did not happen. The dialogue software might be still busy with other stuff.
Additional activities might distract then from temporary technical difficulties.

just as you went into a "delay", and that would be your indication as to why....

I found questionable software behaviour also for other components in the suggested way so that corresponding clarification requests and bug reports were published.