Created attachment 70827 [details] [review]
Batch stat()s

Step 1: make sure you are comparing against the correct versions.

strace during program start-up:
               % time     seconds  usecs/call     calls    errors syscall
v2.8.x:         77.53    0.529482           5    106929       567 stat64
v2.10.vanilla:   8.46    0.009094          17       549       264 stat64
v2.10.batched:   8.50    0.009368          18       529       244 stat64

Can you please explain those numbers?  Why was 2.8 making 200 times more calls?
And what is the effect of your patch in the numbers above?

The application uses a few GtkFileChooserButtons. In v2.8 these scanned the directories (including those of the shortcuts) during creation. This behaviour was fixed in v2.10 so that only the active directory was scanned as required (on map, folder changed etc) - part of the async file chooser work, AIUI.

For example, v2.8 scanned my home directory 115 times, where as v2.10.1 not once.

The upshot is I was chasing a problem that had already been fixed. However, I think deferring the stat() to an idle handler still has merit and seems a natural fit with the async interface.

Ping? Am I missing something or the numbers show this does not improve anything? In your last comment you still think the idea has merit though. Planning to do more testing? Should we close this?

This is only one part of the bottleneck in displaying the FileChooser dialog and it does not alleviate the construction of the TreeView as that still waits for the entire directory to be scanned before starting.

This bug is a solution(?) searching for a problem... One day I'll make the mistake of trying to open a file from within a large directory (preferably a really slow remote fs) and be inspired to profile and measure the latency.