AutoHotkey Community

i already know that this can be achieved by using SplitPath on A_LoopFileFullPath... but that takes too much time if u r operating on too much files... so i think it'll be easy to add some more variables in a File/Folder loop ?...

Thanks, but it seems too rarely needed to justify the added code size.

The command SplitPath should not noticably slow down a file-pattern loop. If you have results that prove otherwise, please let me know.

Note: File-pattern loops and file-reading loops can be accelerated by specifying SetBatchLines -1 beforehand.

I once needed to find a file through my friends' hard Disk ... and as he was a pro computer user... his hard contained more than 660000 files and folders... so i created a script that searched the file ... but it took 21 seconds more if i added SplitPath to look for specific Extensions...

another question...
the script i just talked about used about 20% of my cpu (SetBatchLines, -1 - Priority, Realtime) ... while some other applications can utilize upto 100% cpu... i.e they will run fast... so why doesnt AHK uses whole cpu..? and on HT systems (Intel Hyper threading) does AHK performs two threads at a time?.. thanks

I tested SplitPath and could see that it slows down file scanning. Testing shows that a built-in variable A_LoopFileExt would only use half as much CPU time as SplitPath. Due to this plus the convenience of A_LoopFileExt, it will be in the next update. Thanks for suggesting it and posting your performance findings.

As for your other question, the reason the CPU is not maxed by a file-pattern loop is that the file system was probably not in the cache at the time of the operation. As a result, the script is forced to spend much of its time (80% in this case) waiting for the hard disk to provide the info it needs to continue. This would be true of any disk intensive process, not just a script.

In this case, adding more threads to the program (each script currently has only one thread) might actually slow it down because the the hard disk is then often forced into a more random pattern of access, which moves the drive head more, which in turn might slow everything down to a crawl.

One thing that would probably speed things up is that when you have more than one physical drive. In that case, having a separate instance of the script running for each drive would allow all drives to be accessed in parallel. This might as much as double the speed of the operation (or triple for three drives, etc.)

Edit: A_LoopFileExt has been added in v1.0.36.02.

Thanks for A_LoopFileExt



I do have two Physical Drives...but there is no way in ahk that i can find which Drive letters belong to the first one and which to second one... ? and other than that... if i do write specific letters (not by DriveGet) and run two scripts... i'll need to combine the two variables... how do i do that?..
THanks

It'll be great if A_LoopFileDrive get added too
thanks

I don't think there's any direct way, but perhaps there is a way using an OS Comspec command, or via DllCall() to query the drive.

There are several ways to share data between scripts. One of the easiest is with a temp file on disk (IniWrite/Read and/or FileAppend/FileRead). Another way is via the clipboard. By using ClipboardAll, the clipboard can be used in this fashion without losing anything the user may have had on it beforehand.

It seems like that would be much less often used than A_LoopFileExt. Therefore, in keeping with the principle that a line must be drawn somewhere to keep the code size in check, it seems best not to add it.

Thanks.