There is no timer code, and it uses the listbox. PS can CREATE a listbox on the screen, but that's probably overkill at this point.
Load the names into a flat file like I did, add timer output, and we'll have something to run on each others system. Once there's 3 versions, I'll add the 4th.
I had an FSO version in my benchmark which wasn't any competition at all to the Dir and API versions.
Here I post the final program with multiple versions of the scan procedure, including the little timing dll (which is rather good), so as you can add procedures at your own gusto to compare them.
The structure is all the same: Add a button like there are already some, copy their code into the new button's click handler, change the call to your selfwritten procedure.
@vb5prgrmr: I had put your code into a module to include it, and - I'm sorry - stripped it from some comments to understand the structure. Sorry. I better understand if I see plain code.
Well, I wanted a version that produced a text file. That's why I posted the code that I had, that had no timing in it. I was going to do the Powershell version to write the same text file, and time it.
The listbox is a different animal with .Net. Slower the first time to deploy...
That won't work. You'll HAVE to download Powershell, and run the script on your folder to get true timing. I can do it, and post my findings of the VB6 folder again. That takes about 10 seconds to run, on the new system. When I wrote it, it took about 3 minutes to trundle thru.
Upgraded a few things since then, though. I didn't do the PS script either, other than the basic one I showed. I think it will be an order of magnitude faster than the VB6 version.
Hmm, although running it 10 times in a loop might show the differences better.
Just remember that the original intent was to use this in VB so creating a file outside of VB is not a true test one must call the script from VB and get that data into VB for processing as part of the test as well.
The time should reflect all 3 processes to be accurate.
Yeah, DataMiser, that's what I thought, too. If you do a powershell schript, you'd have to shell to it and wait for it to terminate and have the file written.
I mean, what's the use and comparison elsewhile. If I say, hey, I have to scan for a file in Vb6, the answer: power shell can do it, is not an option, except I can use the power shell result in VB again.
Also a loop of 10 times through will not give accurate results as in a real world senario it will be ran only once, Most of the time will be on the first run after that everything is in memory and runs much faster.
If I do a search on a directory here maybe the first time will take 7 seconds but if I run it again and again and again each time ofter the first may only take 2 seconds or less so if we ran it 10 times we would come up with an average times that is far faster than it would be in actual use.
I was going to run some tests with powershell but it appears I do not have it on any of my machines. I guess referring to it as the new dos is a bit of an exageration seeing as how windows 7 does not install it nor does VS2010.
From what I have saw online it does appear to have a lot more overhead than Dos however.
I had an FSO version in my benchmark which wasn't any competition at all to the Dir and API versions.
Here I post the final program with multiple versions of the scan procedure, including the little timing dll (which is rather good), so as you can add procedures at your own gusto to compare them.
The structure is all the same: Add a button like there are already some, copy their code into the new button's click handler, change the call to your selfwritten procedure.
@vb5prgrmr: I had put your code into a module to include it, and - I'm sorry - stripped it from some comments to understand the structure. Sorry. I better understand if I see plain code.
I ran your program on my system and pointed at my program files folder searching for *.* All methods took between 3 and 3.5 seconds with the exception of the FSO which took 19.5 seconds
The dos Dir method redirected to file took about 2.8 seconds to generate the file from the command line of course by the time we shell to it and then parse the results it would take as long or longer than the tests above done in VB6.
I also ran a test in VB 2005 using the directory.getdirectories() and directory.getfiles() and adding them to an invisible listbox.
time varied a bit 12 seconds to 13.5 seconds.
ETA: sorry the time was actually pretty steady at 12 seconds. The 13.5 was before I hid the listbox.
Last edited by DataMiser; May 23rd, 2010 at 06:21 PM.
Tried another .net test that I thought might be faster but turned out to be a couple of seconds slower.
This code steps through each directory in the tree and grabs the filenames from each of them adding the file name to the listbox.
Takes 12 seconds on my test machine
Code:
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
ListBox1.Items.Clear()
Dim x As DateTime = Now()
ListBox1.Visible = False
For Each strFolder As String In Directory.GetDirectories("c:\program files", "*.*", SearchOption.AllDirectories)
For Each strFile As String In Directory.GetFiles(strFolder, "*.*", SearchOption.TopDirectoryOnly)
ListBox1.Items.Add(strFile)
Next
Next
ListBox1.Visible = True
MsgBox(DateDiff(DateInterval.Second, x, Now()))
End Sub
This test grabs all the directories first then grabs all the filenames.
Takes 14 seconds on the test machine.
Code:
Private Sub Button2_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button2.Click
ListBox1.Items.Clear()
Dim x As DateTime = Now()
ListBox1.Visible = False
For Each strFolder As String In Directory.GetDirectories("c:\program files", "*.*", SearchOption.AllDirectories)
ListBox1.Items.Add(strFolder)
Next
For Each strFile As String In Directory.GetFiles("c:\program files", "*.*", SearchOption.AllDirectories)
ListBox1.Items.Add(strFile)
Next
ListBox1.Visible = True
MsgBox(DateDiff(DateInterval.Second, x, Now()))
End Sub
* The Best Reasons to Target Windows 8
Learn some of the best reasons why you should seriously consider bringing your Android mobile development expertise to bear on the Windows 8 platform.
If your question has been answered satisfactorily, and it has been helpful, then, please, Rate this Post!
Reply With Quote
Originally Posted by WoF
