tzuk, before you explode
about another "speed complaint" topic, hang on, I think this deserves its own fresh topic! This is like a new slate. 
I love Sandboxie too much, and I think my curiousity about what I've been seeing finally paid off BIG a few days ago. 
I did some debugging in a way that I almost did 2-3 months ago, but didn't feel like then.I now have some concrete specifics about what's going on... I think there are certain ODD window classes (but common and general) that are being "processed" or whatever, in a way that's degrading performance. A single one of them has an impact, and the few "problem classes," as a whole, are responsible for the vast, vast majority of the slowdown I see! I can't understand why this would be, but maybe (hopefully) you can make sense of it.
The "good news" is: there's actually no difference using OpenWinClass with or without a program-specific prefix (other than special global * case, of course); it's not related to * wildcard settings or $:explorer.exe (those settings only include the "problem classes"); and there doesn't seem to be ANY performance problem with OpenWinClass matches going through the SbieSvc.exe GuiProxy process. First, the simple browser benchmark script I just thought of and created quickly a few weeks ago. For anyone that wants to check their "browser window creation performance" in Sandboxie (it's been mostly Internet Explorer-specific for me, although I see similar relative performance with Firefox on my main system). Very simply, you can try the benchmark with these different Sandboxie settings (close browser fully, Reload Configuration between):
Default settings
With OpenWinClass=*
With OpenWinClass=BROWSER.exe,*
You could also use OpenWinClass=$:explorer.exe or with the list of "problem classes" below. For reference, the relative differences I see at minimum with IE are: OpenWinClass=BROWSER.exe,* twice as slow as default settings; and the "problem classes" twice as slow as OpenWinClass=*
Here's the page: Sandboxie Browser Window Benchmark You can run the "window opening" test right from the page (it runs fully in your browser, so no network delay), or download a couple files to your local system if you want to measure browser process creation and window opening time (but the online test is fine and will show same general results). Let us know your results with different settings.
tzuk, or anyone else that doesn't see a difference: The minimum differences I see do apply to XP/IE 6 and Win 7 (64)/IE 8 (32) with as little "window-y stuff" running as possible. On my main XP/IE 6, I see HUGE differences with just a few of my usual windows open, e.g. window opening 0.2s with Open=*, 0.7s defaults, and 4s with the "problem classes" below. So, on a real-world system with enough normal "stuff" running, it seems differences should be noticable.
Now, those "problem classes" -- I think maybe these are always being "processed" wrong, slowly, etc. (which would explain some slowness even with defaults), and the differences are just "magnified" when they're part of OpenWinClass.
On XP, it's these (ordered from worst to least impact), responsible for 90%+ of slowdown:
SysPager (MAJOR impact... not to be confused with SysFader)
BaseBar
TPUtilWindow
Tooltips_class32
ComboLBox
GamingCommandStateMachineWindow
WorkerW (small impact, but measurable)
Explorer is FULL of BaseBar and SysPager, so that explains my results with $:explorer.exe! GamingCommandStateMachineWindow is only in my old MS keyboard/mouse software processes (IntelliType/IntelliPoint), so that's not a universal one. TPUtilWindow looks like a Delphi thing...?
On 64-bit 7, it's these (less variation, worst to least), responsible for ~80% of slowdown:
Tooltips_class32
IME
MSCTFIME UI
WorkerW
That's not meant to be a complete, exhaustive list. There are still some with whatever characteristics these have that are having a smaller cumulative impact... But I can use OpenWinClass with A* ... Z* (all at once) minus the letters of the problem classes and there's only a small difference, e.g. matching most other classes doesn't cause much of a problem.
Finally, reasons I don't think requests going through GuiProxy is an issue: The performance with global OpenWinClass=*, of course, even before the change in 4.03.01. Assuming your description of "everything goes through GuiProxy" was correct, that proves GuiProxy was/is not an issue. No, Open=* was always a special case, even in 4.01.04 that I recently checked, so the difference/optimization must come before GuiProxy? Although it seems Open=* got "more optimized" in 4.01.05 after the other GUI optimizations.
Also, I just remembered and verified the results with PerformanceTest's 2D Windows Interface benchmark! After the optimizations in 4.01.05, I said I noticed better performance sandboxed than not, which was surprising (I can only assume caused by "isolation"). The results are the same (10-20% better) when it's run with default settings OR OpenWinClass=pt.exe,*
If global Open=* is used, performance drops back to UNsandboxed levels (fine, expected). Anyway, I just saw this as proof that GuiProxy is not an issue, even if all the window benchmarking stuff is going through it. In fact, since 4.01.05, there is zero, I repeat, ZERO, CPU usage on the SbieSvc.exe processes when benchmarking. Of course, the benchmark doesn't use any of those "problem classes." Thanks for reading! Hopefully the info/details I provided help my results be reproduced and/or investigated.
Then I tried removing different chunks of letters looking for which ones caused most slowdown. Found S*, for example, which I then tracked down to SysPager. And so on... 
(And again, no need to post "Normal" and "Pop-up" results -- if there's no difference, they're the same. 
), and before I was going to reply Friday, I was verifying numbers, etc. again... And I THOUGHT I had verified same behavior on 4.02 initially, but either I didn't or I was wrong. Unlike 4.04, 4.02 does NOT speed up to UNsandboxed performance with OpenWinClass=* 
