http://bugzilla.wpkg.org/show_bug.cgi?id=233 Summary: Command invokations cause unneccessary delays Product: WPKG Version: other Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: wpkg.js AssignedTo: mangoo at wpkg.org ReportedBy: malte at malte.homeip.net QAContact: wpkg-users at lists.wpkg.org Created attachment 206 --> http://bugzilla.wpkg.org/attachment.cgi?id=206 Proposed enhancement in execution time Whenever wpkg.js executes some external command, it enters a polling loop to wait for the process to exit. This loop has a delay of 1000ms, which can add up to quite some delay for just idling around. This isn't so much of a problem when actually installing something, but when using "execute" type checks, it can severely slow down the boot process. While Windows performs quite badly wrt. spawning a lot of processes anyway and WSH has its share, too, WPKG should probably not add that much of a delay on top of it. Test case: <package id="exec-speed-demo" name="Execution Speed Demo"> <check type="execute" path="cmd /cecho."/> <check type="execute" path="cmd /cecho."/> <check type="execute" path="cmd /cecho."/> <check type="execute" path="cmd /cecho."/> <check type="execute" path="cmd /cecho."/> <check type="execute" path="cmd /cecho."/> <check type="execute" path="cmd /cecho."/> <check type="execute" path="cmd /cecho."/> <check type="execute" path="cmd /cecho."/> <check type="execute" path="cmd /cecho."/> <check type="execute" path="cmd /cecho."/> <check type="execute" path="cmd /cecho."/> <check type="execute" path="cmd /cecho."/> <check type="execute" path="cmd /cecho."/> <check type="execute" path="cmd /cecho."/> <check type="execute" path="cmd /cecho."/> <check type="execute" path="cmd /cecho."/> <check type="execute" path="cmd /cecho."/> <check type="execute" path="cmd /cecho."/> <check type="execute" path="cmd /cecho."/> </package> Without the attached patch, wpkg.js /install:exec-speed-demo takes ~22s. With the patch, this drops down to ~4s. Sure such a packge should rather just execute one script for the complete check, but the same holds for 20 individual packages with just one execute check each. The change in timeout handling is intended to prevent summing up the expected high inaccuracies of ten times as many WScript.Sleep() calls. I'd consider 100ms a good compromise between not hogging the CPU and an acceptable response time for "execute" checks. Thanks for considering! -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. |