Sorry didn't reply sooner! Nothing yesterday, but the previous 2 days, I thought I had some extra feedback, and then shortly later I realized something else or that I was wrong... Anyway, so not much different to report than my last post, although there is one big mistake (or not) I made with my CreateWindow benchmark!
I guess you didn't see my code, but I realized Tuesday when checking something else. This was the benchmark code:
Code: Select all
HWND dummy = CreateWindowA("Static", "Dummy test", WS_CHILD, 0, 0, 128, 64, NULL, NULL, NULL, NULL);
DestroyWindow(dummy);
I said any CreateWindow call seemed to behave the same in Sandboxie -- didn't matter if custom class or standard Static/Edit/etc., or what the other parameters were. So I was just using 0s everywhere. Except I noticed if I didn't use WS_CHILD, it was much slower UNsandboxed, so I figured it needed some style flag. BUT I've now realized that WS_CHILD without a parent HWND is also invalid which is why it runs SO FAST UNsandboxed! (10^6 in 1.3s). I've updated it with a parent param.
Updated
GUIBench.zip and
source/
package.
Oops, sorry!
Now what I realized doesn't really change anything in Sandboxie, it's just that the UNsandboxed result was way off, and made Sandboxie look bad with a lot of overhead that's not really there! e.g. Sandboxed is actually only a few times slower than UNsandboxed (expected) up to
10's of times slower at worst, NOT 100s or 1000s of times slower.
The bigger speed difference I saw with CreateWindow in API Monitor (before creating "supporting" benchmark) must be coming from other stuff within the CreateWindow calls, rather than only the CreateWindow function itself...
BTW, I also verified the slowness I see using API Monitor itself is not related to CreateWindow (not that I thought it was).
PowerArchiver: I was only checking laptop before, which hasn't had PA installed for a long while. I've since upgraded to the latest betas on main system to check my 2011 PA version. The results are about what I expected (like the IE window opening speed).
In my main active sandbox (with OE, 2 IEs, Pale Moon running), Configuration window took just over
3 seconds to open with old DLL (defaults). Just over
2 seconds with new DLL -- and no OpenWinClass settings make it slower, so no 50 second extreme.
However, in a sandbox by itself, it's right around
1 second (about half-second UNsandboxed). So those few other things open in other sandbox add a second.
CreateWindow benchmark, 10^
3 iterations on main system takes 1.25s UNsandboxed, ~10s with old DLL, and ~6s new DLL (main active sandbox; ~2s on its own). So instead of adding 0.01s I mentioned, old DLL was "just" 0.009s and new DLL adds 0.005 per call. Savings of 0.004 reflects the times I see: PA Configuration, 270 CreateWindow calls * 4ms is about a second saved.
IE window opening: from 0.7s to 0.58, which again is right for 30-ish CreateWindows.
Now, about those drastic slowdowns I see with the new DLL (using hopefully valid CreateWindow calls
). 10^
4 iterations on laptop takes ~1.5s UNsandboxed. I guess there is a slight slowdown in Windows since the slower laptop is doing 10x more calls in almost the same time as main system with a lot more window stuff open...
Same 10^
4 iterations:
- 3.76
4.6s alone
6.4s with 1 IE window
17.8s with 10 IE windows
- 4.05.03
15.8s alone
19.6s with 1 IE window
42.6s with 10 IE windows
- 4.05.04
~4s alone
7.5~10s with 1 IE window
44~49 with 10 IE windows
Besides the rapid degradation itself, something doesn't seem right that it becomes slower than the previous DLL/version if the same "window notification" stuff is happening, but without the GuiProxy overhead? The new version can beat 3.76 initially. It would be nice if the algorithm, etc. performance could stay with it.