As you may be aware I use an AIO Autopatcher, noticed running Sweeper on this takes quite a bit of time. Was wondering is there a possibility to have Sweeper only run on the releases that contain the errant files??
This would cut down the runtime required... Just a suggestion at this stage.
A possible suggestion for Sweeper
- Whatacrock
- Release Maintainer
- Posts: 1967
- Joined: Mon Oct 28, 2013 10:47 am
- Location: Australia
- Contact:
A possible suggestion for Sweeper
"Now if you Sons of B*@ches got anything else to say, NOW'S THE F@#%ING TIME!!"
Re: A possible suggestion for Sweeper
Are you talking about running manually or auto run? If its auto run you are concerned about, I suppose I could throw in a box that lets you pass commands to sweeper so you can run it without md5. Possibly even just an entry in the ini file. As for running it manually passing in the switch (skip_md5) to remove MD5 checks makes it much faster.
Other then that. There isn't much of a way to increase speed noticeably beside removing size checks as well (skip_size). The only way to find the errant files in a release it to check the files.
I suppose now that the releases are separated by directories I can run a quick file count check to look for extra/missing files and that would be supper fast but, that would never find files that were changed.
If you run sweeper and watch your cpu you can see that on even older computers the cpu isn't taxed all that much its the HD that is the bottleneck. It has to read in the entire contents of every file to generate a MD5 hash. hmm.. I 'might' be able to make that a tad faster by switching the MD5 hash to use windows API cripto instead of the custom one. Windows API will use hardware encryption and tricks that the custom one does not. It probably even plays around with pre-reading files before they are asked for.
Other then that. There isn't much of a way to increase speed noticeably beside removing size checks as well (skip_size). The only way to find the errant files in a release it to check the files.
I suppose now that the releases are separated by directories I can run a quick file count check to look for extra/missing files and that would be supper fast but, that would never find files that were changed.
If you run sweeper and watch your cpu you can see that on even older computers the cpu isn't taxed all that much its the HD that is the bottleneck. It has to read in the entire contents of every file to generate a MD5 hash. hmm.. I 'might' be able to make that a tad faster by switching the MD5 hash to use windows API cripto instead of the custom one. Windows API will use hardware encryption and tricks that the custom one does not. It probably even plays around with pre-reading files before they are asked for.
- Whatacrock
- Release Maintainer
- Posts: 1967
- Joined: Mon Oct 28, 2013 10:47 am
- Location: Australia
- Contact:
Re: A possible suggestion for Sweeper
As I said just a suggestion.
Here is an example scenario:
Have run autopatcher, states "Unofficial", check the log and find that Windows Vista has errant files (modules or installers) left behind. Manually run Sweeper to clean up. As my AIO contains releases from Windows XP x86 all the way to Windows 8.1 x64 plus all the extra releases, then must wait for Sweeper to complete. So what I was suggesting is if sweeper would only be required to check the Windows Vista release, and then delete the files.
Probably making things harder than necessary, not everyone uses autopatcher in the same way, needing only the releases they are running or installing updates on machines they maintain..
Here is an example scenario:
Have run autopatcher, states "Unofficial", check the log and find that Windows Vista has errant files (modules or installers) left behind. Manually run Sweeper to clean up. As my AIO contains releases from Windows XP x86 all the way to Windows 8.1 x64 plus all the extra releases, then must wait for Sweeper to complete. So what I was suggesting is if sweeper would only be required to check the Windows Vista release, and then delete the files.
Probably making things harder than necessary, not everyone uses autopatcher in the same way, needing only the releases they are running or installing updates on machines they maintain..
"Now if you Sons of B*@ches got anything else to say, NOW'S THE F@#%ING TIME!!"
Re: A possible suggestion for Sweeper
Ok I see what you mean now.
Hmm I could possibly have the INI store root directories found to be bad. Sweeper picks that out and scans just the bad releases. It is doable. Would add a switch for that though. The default probably should always be full scan.
Hmm I could possibly have the INI store root directories found to be bad. Sweeper picks that out and scans just the bad releases. It is doable. Would add a switch for that though. The default probably should always be full scan.
Re: A possible suggestion for Sweeper
So a port of the sweeper code to VB.net was pretty damn easy and already works for the most part. Will poke it a bit tomorrow or the next day.
- Whatacrock
- Release Maintainer
- Posts: 1967
- Joined: Mon Oct 28, 2013 10:47 am
- Location: Australia
- Contact:
Re: A possible suggestion for Sweeper
Great, will wait and see
![Smile :)](./images/smilies/icon_e_smile.gif)
![Smile :)](./images/smilies/icon_e_smile.gif)
![Smile :)](./images/smilies/icon_e_smile.gif)
"Now if you Sons of B*@ches got anything else to say, NOW'S THE F@#%ING TIME!!"
Re: A possible suggestion for Sweeper
Did some preliminary work . Won't be around tomorrow to finish it though. Good news is that it will only require the ExtraTools.dll and 7za. Well and .Net 2.0 <- everyone should have this though.
Re: A possible suggestion for Sweeper
So I was ready to post a version for you to try out when I found an issue. When VB.net builds an application it demands all the DLLs linked to your app via reference be included in the same directory and modified by VB.net. sigh. I can't figure out how to make it NOT do that so, I am now recreating the wheel so to speak with making a dozen or so new functions (its a nice learning experience about VB.Net stuff while I am at it). It should only be 2 files and the ziper in bin... right now its 7 files.
- Whatacrock
- Release Maintainer
- Posts: 1967
- Joined: Mon Oct 28, 2013 10:47 am
- Location: Australia
- Contact:
Re: A possible suggestion for Sweeper
If this is going to be an issue, then place on the back burner and leave to some time in the future, as I said it was just a suggestion.
Not that difficult, just sit back and wait for Sweeper to complete it's task, make a brew and enjoy the caffeine...
Not that difficult, just sit back and wait for Sweeper to complete it's task, make a brew and enjoy the caffeine...
"Now if you Sons of B*@ches got anything else to say, NOW'S THE F@#%ING TIME!!"
Re: A possible suggestion for Sweeper
Well this will directly affect the new AP as well since it uses the same files. So fix it now or later still the same issue.
As for your issue you could just download them separately and then have a batch file put them all together.![Smile :)](./images/smilies/icon_e_smile.gif)
As for your issue you could just download them separately and then have a batch file put them all together.
![Smile :)](./images/smilies/icon_e_smile.gif)