Tree View question.

[lingo]

Long time ago I "invented" that DispatchMessage API is faster than SendMessage API,
so I like this prog and re-wrote it with DispatchMessage API only... :wink

[hutch--]

Lingo,

Thanks for the example. I have run it alongside Tedd's but it has a distinct lag on the first click on a drive. I tested it back and forth against Tedd's but his is always faster on the drive click where there are many subdirectories on the first level of expansion.

[lingo]

"it has a distinct lag on the first click"

Every job has its technological time.  :P
If you want to "hid out" it particularly  just comment the "push offset msg1 + call edi" and
"push offset msg2 + call edi" in the "MWP_WM_NOTIFY:"  part. 

[lingo]

I updated it but with FindFirst & FindNext I can't achieve more speed.... :wink

[hutch--]

Lingo,

Thansk for the example but it has the same problem, Tedd's is a lot faster on the first click, I have been testing it on deeply nested directories and Tedd's is uniformly fast where both of yours have a distinct lag when you click on a deeply nested directory. I have not had a good look at it but are you recursing extra depths in each pass with the FindFirstFile() code ?

[lingo]

"of yours have a distinct lag when you click on a deeply nested directory"

I tested it before to post the new update and they (my last update and Tedd's) have equal times for
"distinct lag" on the first click after restarting the PC.
I tested with C:\Windows\winsxs folder of Win7 64bit OS and the time is 15 sec for both.
Next I tested with C:\Windows\winsxs folder of Vista 64bit and the time is 29 sec for both.
For me the bottleneck  is in FindFirst & FindNext APIs.
When I have time I will try with NtQueryDirectoryFile from Ntdll.dll.. :P

[Tedd]

Is this even necessary, Lingo? It was just a quick example I put together on a Sunday afternoon. I realise you have a need to make everything faster, but wouldn't you waste your time much more efficiently elsewhere? :lol
For a freshly booted system, the initial traversing of the directory-tree is going to dominate the time, no matter what method you use - so they will both take roughly the same time in that instance.

[lingo]

"It was just a quick example I put together on a Sunday afternoon"

I like it. :wink :wink

"I realise you have a need to make everything faster"

It is an answer of your 1st question: "Is this even necessary, Lingo?" :P

"waste your time much more efficiently elsewhere?"

I did it but now I'm married and must obey... :lol

"For a freshly booted system, the initial traversing of the directory-tree is going to dominate the time,
no matter what method you use - so they will both take roughly the same time in that instance."

I agree.. :P

[dedndave]

FindFirstFile is slow - i think we all know that
i managed to find one alternative, although, there may be others

The best way to solve your problem seems to be by using the Windows Change Journal.

Problem: If it is not enabled for a volume or the volume is a non-NTFS you need a fallback (or enable
the Change Journal if it is NTFS). You need administrator rights as well to access the Change Journal.

You get the files by using the FSCTL_ENUM_USN_DATA and DeviceIOControll with LowUsn=0. This
directly accesses the MFT and writes all filenames into the supplied buffer. Because it sequentially
acesses the MFT it is faster than the FindFirstFile API.

http://stackoverflow.com/questions/4203573/finding-a-set-of-file-names-quickly-on-ntfs-volumes-ideally-via-its-mft

it seems to me that there may be a way to read the contents of a folder as a file
although, i am not NTFS-savvy enough to know how   :P

on a related note, i have learned that the ms picture/fax viewer can be extremely slow opening a folder
if that folder contains any dead shortcut files (LNK shortcut files that point to non-existung stuff)
this leads me to believe that it tries to locate the targets
not sure if it also applies to URL files   :lol
anyways - thought i would mention it as food for thought

i think if i really wanted to research the subject in depth, i would start with an e-mail to Mark Russinovich   :bg

[lingo]

It is old stuff  from Jeffrey Richter rather than by Russinovich link...

[hutch--]

I am in debt to Tedd for having decyphered the JIT technique for loading a tree view control. On my dev box and the i7 I have alongside it to watch TV, Tedd's technique is clearly the fastest and this is for first time scanning the drive where the JIT technique only scans directories required for display at the selected tree level. I wrote earlier code that did a full drive crawl but on first pass of a drive it was seeing scan time of 30+ seconds with high disk activity for the entire scan time.