Page 1 of 6

Win class performance, cause (NEW), and a test for all

Posted: Sat Jul 20, 2013 3:00 pm
by DR_LaRRY_PEpPeR
Hello all!

tzuk, before you explode :lol: about another "speed complaint" topic, hang on, I think this deserves its own fresh topic! This is like a new slate. :D 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. :)

Posted: Sun Jul 21, 2013 4:26 am
by tzuk
Still on that issue I see. Thanks for your work. I'm not sure I understand in what way you're seeing that those window classes are a problem. Can you give an example, say for SysPager, what do you see that happens with it?

BenchmarkIE

Posted: Sun Jul 21, 2013 5:02 pm
by BUCKAROO
Without OpenWinClass=*, some yet to be determined operations issued at window creation times are either doubly slow or worse. Also please take a look at SketchUp Make's sluggish minimize & restore transition, seeming like it drops its draw surface (briefly white). The slowdown oddities make Sbie 4 seem kludgy, while somehow I know isn't, only seems. ;)
BenchmarkIE - Windows 8 (64-bit) wrote:"C:\Program Files\Sandboxie\SbieIni.exe" set BenchmarkIE Enabled y
(ExitCode 0)
"C:\Program Files\Sandboxie\SbieIni.exe" set BenchmarkIE OpenWinClass
(ExitCode 0)
[BenchmarkIE] OpenWinClass=
920 ms
780 ms
1575 ms
(ExitCode 0)
"C:\Program Files\Sandboxie\SbieIni.exe" set BenchmarkIE OpenWinClass *
(ExitCode 0)
[BenchmarkIE] OpenWinClass=*
530 ms
390 ms
484 ms
(ExitCode 0)
"C:\Program Files\Sandboxie\SbieIni.exe" set BenchmarkIE OpenWinClass
(ExitCode 0)
[BenchmarkIE] OpenWinClass=
921 ms
749 ms
764 ms
(ExitCode 0)
"C:\Program Files\Sandboxie\SbieIni.exe" set BenchmarkIE OpenWinClass *
(ExitCode 0)
[BenchmarkIE] OpenWinClass=*
531 ms
358 ms
593 ms
(ExitCode 0)
"C:\Program Files\Sandboxie\SbieIni.exe" set BenchmarkIE OpenWinClass
(ExitCode 0)
[BenchmarkIE] OpenWinClass=
889 ms
905 ms
983 ms
(ExitCode 0)
Windows 8 (64-bit) wrote:"C:\Program Files\Sandboxie\SbieIni.exe" set BenchmarkIE Enabled y
(ExitCode 0)
[BenchmarkIE] BenchmarkIE
[BenchmarkIE] OpenWinClass=
905 ms
1061 ms
967 ms
[BenchmarkIE] finished. Waited 10.343 seconds.
[BenchmarkIE] BenchmarkIE
[BenchmarkIE] OpenWinClass=*
546 ms
452 ms
468 ms
[BenchmarkIE] finished. Waited 9.110 seconds.
[BenchmarkIE] BenchmarkToolTip
[BenchmarkIE] OpenWinClass=
6178 ms
6614 ms
6989 ms
[BenchmarkIE] finished. Waited 21.668 seconds.
[BenchmarkIE] BenchmarkToolTip
[BenchmarkIE] OpenWinClass=*
3089 ms
3026 ms
2995 ms
[BenchmarkIE] finished. Waited 10.249 seconds.
Windows 7 (32-bit) - VirtualBox wrote:"C:\Program Files\Sandboxie\SbieIni.exe" set BenchmarkIE Enabled y
(ExitCode 0)
[BenchmarkIE] BenchmarkIE
[BenchmarkIE] OpenWinClass=
2323 ms
3055 ms
4847 ms
"C:\Program Files\Sandboxie\Start.exe" /box:BenchmarkIE /terminate
(ExitCode 0)
[BenchmarkIE] terminated. Waited 28.010 seconds.
[BenchmarkIE] BenchmarkIE
[BenchmarkIE] OpenWinClass=*
1151 ms
2063 ms
1392 ms
"C:\Program Files\Sandboxie\Start.exe" /box:BenchmarkIE /terminate
(ExitCode 0)
[BenchmarkIE] terminated. Waited 18.566 seconds.
[BenchmarkIE] BenchmarkToolTip
[BenchmarkIE] OpenWinClass=
19137 ms
19839 ms
19679 ms
[BenchmarkIE] finished. Waited 60.867 seconds.
[BenchmarkIE] BenchmarkToolTip
[BenchmarkIE] OpenWinClass=*
8632 ms
8081 ms
8492 ms
[BenchmarkIE] finished. Waited 27.379 seconds.
[BenchmarkIE] BenchmarkIE
[BenchmarkIE] OpenWinClass=
2163 ms
3175 ms
2914 ms
"C:\Program Files\Sandboxie\Start.exe" /box:BenchmarkIE /terminate
(ExitCode 0)
[BenchmarkIE] terminated. Waited 15.973 seconds.
[BenchmarkIE] BenchmarkIE
[BenchmarkIE] OpenWinClass=*
1182 ms
1563 ms
1192 ms
"C:\Program Files\Sandboxie\Start.exe" /box:BenchmarkIE /terminate
(ExitCode 0)
[BenchmarkIE] terminated. Waited 19.799 seconds.
BenchmarkIE
http://l.autohotkey.net/

Code: Select all

/*
*** UNSANDBOXED ***
Save script as BenchmarkIE.ahk
Unregistered Sandboxie users,
save script as DefaultBox.ahk
Drag & Drop onto AutoHotkey.exe
*** UNSANDBOXED ***
*/

#SingleInstance off

Global WCHAR:=2
Global TCHAR:=A_IsUnicode?WCHAR:1
Global MAX_PATH:=(32767*TCHAR)+TCHAR

;Global _ScriptName:=RegExReplace(A_ScriptName,"i)[^0-9A-Z_]","_")
Global _ScriptName:=RegExReplace(A_ScriptName,"i)([0-9A-Z_]+).*","$1")

Global _AhkPath
if(A_IsCompiled)
	_AhkPath="%A_ScriptFullPath%"
else
	_AhkPath="%A_AhkPath%" "%A_ScriptFullPath%"

params=%0%
Loop,%0%
	param%A_Index%:=%A_Index%

Process,Exist
Global _ScriptPID:=ErrorLevel

if(param1=="BOXED")
{
	Global BOXED:=true
	
	if(!DllCall("AttachConsole","UInt",param2))
		MsgBox,AttachConsole()	error`n%A_LastError%
	
	;SetTitleMatchMode,RegEx
	SetTitleMatchMode,3
	SetTitleMatchMode,Fast
	DetectHiddenWindows,Off
	
	if param3 contains BenchmarkIE
	{
		Target=%ProgramFiles%\Internet Explorer\iexplore.exe
		;SetBatchLines,-1
		Loop,3
		{
			StartTime:=A_TickCount
			Run,%Target%,,Max
			;Run,%Target%,,Min
			;Run,%Target%,,Hide
			WinWait,ahk_class IEFrame
			ElapsedTime:=A_TickCount-StartTime
			Console("ECHO	" ElapsedTime " ms")
			WinClose
			WinWaitClose
		}
	}
	else if param3 contains BenchmarkToolTip
	{
		;SetBatchLines,-1
		Loop,3
		{
			StartTime:=A_TickCount
			Loop,1000
			{
				ToolTip,%A_Index%,%X%,%Y%
			}
			ElapsedTime:=A_TickCount-StartTime
			Console("ECHO	" ElapsedTime " ms")
		}
	}
	
	ExitApp
}

if(false&&!A_IsAdmin)
{
	Run,*RunAs %_AhkPath%,%A_ScriptDir%,UseErrorLevel
	ExitApp
}

DllCall("AllocConsole")
Console()

if(A_PtrSize==4&&A_Is64bitOS)
	Global Sandboxie32:="\32"

Global SbieDll,SbieExe,SbieIni

SbiePathCandidates:=[]
SbiePathCandidates.Insert(Object("RootKey","HKEY_LOCAL_MACHINE","SubKey","SYSTEM\CurrentControlSet\Services\SbieDrv","ValueName","ImagePath"))
SbiePathCandidates.Insert(Object("RootKey","HKEY_LOCAL_MACHINE","SubKey","SYSTEM\CurrentControlSet\Services\SbieSvc","ValueName","ImagePath"))
SbiePathCandidates.Insert(Object("RootKey","HKEY_LOCAL_MACHINE","SubKey","SYSTEM\CurrentControlSet\Services\EventLog\System\SbieDrv","ValueName","EventMessageFile"))
SbiePathCandidates.Insert(Object("RootKey","HKEY_LOCAL_MACHINE","SubKey","SYSTEM\CurrentControlSet\Services\EventLog\System\SbieSvc","ValueName","EventMessageFile"))
SbiePathCandidates.Insert(Object("RootKey","HKEY_LOCAL_MACHINE","SubKey","SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Sandboxie","ValueName","DisplayIcon"))
SbiePathCandidates.Insert(Object("RootKey","HKEY_CURRENT_USER","SubKey","Software\Microsoft\Windows\CurrentVersion\Run","ValueName","SandboxieControl"))

For IntKey,SbiePathCandidate in SbiePathCandidates
{
	RegRead,OutputVar,% SbiePathCandidate.RootKey,% SbiePathCandidate.SubKey,% SbiePathCandidate.ValueName
	StringReplace,OutputVar,OutputVar,",,All
	StringReplace,OutputVar,OutputVar,\??\
	SplitPath,OutputVar,,OutDir
	SbieDll:=OutDir Sandboxie32 "\SbieDll.dll"
	SbieExe:=OutDir "\Start.exe"
	SbieIni:=OutDir "\SbieIni.exe"
	if(FileExist(SbieDll)&&FileExist(SbieExe)&&FileExist(SbieIni))
	{
		happy:=true
		break
	}
}

try
{
	if(!happy)
		throw
	
	Global hSbieDll:=DllCall("LoadLibrary","Str",SbieDll,"UPtr")
	Global SbieApi:={EnumBoxes:0,EnumProcessEx:0,QueryBoxPath:0}
	For Proc,Address in SbieApi
	{
		SbieApi[Proc]:=DllCall("GetProcAddress","UPtr",hSbieDll,"AStr","SbieApi_" Proc,"UPtr")
		if(!SbieApi[Proc])
			throw
	}
	
	Global boxed_pids
	VarSetCapacity(boxed_pids,4*512)
}
catch
{
	if(!happy)
		MsgBox,Not happy!
	else
		MsgBox,Unhandled exception.
	
	ExitApp
}

Global SandboxTerminated

Target="%SbieIni%" set %_ScriptName% Enabled y
RunWait(false,Target)

Gui,1:+AlwaysOnTop +Caption +OwnDialogs -Resize 

Global OpenWinClass
Gui,1:Add,Text,W300 +BackgroundTrans,OpenWinClass=
Gui,1:Add,Edit,W300 VOpenWinClass GOpenWinClass -Wrap
Gui,1:Add,Button,W300 GAsterisk,*
Gui,1:Add,Button,W300 GTerminate,Terminate [%_ScriptName%] Programs
Gui,1:Add,Button,W300 GBenchmarkIE,Benchmark IExplore`n(timed from process create to moment window visible)
Gui,1:Add,Button,W300 GBenchmarkToolTip,Benchmark ToolTips`n(keeping mouse still versus movement affects results)
Gui,1:Show,AutoSize
return

GuiClose:
Gosub,Terminate
ExitApp

OpenWinClass:
Gui,1:Submit,NoHide
return

Asterisk:
GuiControl,,OpenWinClass,% OpenWinClass?"":"*"
return

Terminate:
Terminate(false)
return

BenchmarkIE:
BenchmarkToolTip:
Benchmark(A_ThisLabel)
return

Terminate(silent:=true)
{
	Target="%SbieExe%" /box:%_ScriptName% /terminate
	return SandboxTerminated:=RunWait(silent,Target)==0
}

Benchmark(_ThisLabel)
{
	static recursive:=0
	if(recursive>0)
		return
	++recursive
	
	try
	{
		Gui,1:+OwnDialogs
		
		_OpenWinClass:=OpenWinClass
		
		Console("ECHO [" _ScriptName "] " _ThisLabel)
		
		if(!Terminate())
			throw "Failed to Terminate Programs."
		SandboxTerminated:=false
		
		Target="%SbieIni%" set %_ScriptName% OpenWinClass "%_OpenWinClass%"
		if(RunWait(true,Target))
			throw "Failed to set OpenWinClass=" _OpenWinClass
		
		Console("ECHO [" _ScriptName "] OpenWinClass=" _OpenWinClass)
		
		Target="%SbieExe%" /box:%_ScriptName% %_AhkPath% BOXED %_ScriptPID% %_ThisLabel%
		;SetBatchLines,-1
		StartTime:=A_TickCount
		RunWait,%Target%
		;ExitCode()
		Loop
		{
			if(DllCall(SbieApi.EnumProcessEx,"WStr",_ScriptName,"UChar",FALSE,"UInt",-1,"UPtr",&boxed_pids,"Int"))
			{
				MsgBox,SbieApi_EnumProcessEx()	error
				break
			}
		}
		Until !NumGet(boxed_pids,"UInt")
		ElapsedTime:=A_TickCount-StartTime
		
		SetFormat,float,0.3
		Console("ECHO [" _ScriptName "] " (SandboxTerminated?"terminated":"finished") ". " "Waited " ElapsedTime/1000 " seconds.")
	}
	catch str
	{
		if(!StrLen(str))
			str:="Unhandled exception."
		Console("ECHO " str)
	}
	
	--recursive
}

ExitCode(silent)
{
	ExitCode:=ErrorLevel
	if(!silent)
		Console("ECHO (ExitCode " ExitCode ")")
	return ExitCode
}

RunWait(silent,Target,WorkingDir:="",Max_Min_Hide_UseErrorLevel:="",ByRef OutputVarPID:="")
{
	if(!silent)
		Console("ECHO " Target)
	RunWait,%Target%,%WorkingDir%,%Max_Min_Hide_UseErrorLevel%,OutputVarPID
	return ExitCode(silent)
}

Console(ByRef str:="")
{
	system("COLOR " (BOXED?"0E":"0F") "&TITLE " _ScriptName)
	if(str)
		system(str)
}

system(ByRef str)
{
	return DllCall("msvcrt\system","AStr",str,"Cdecl " "Int")
;	return DllCall("msvcr100\system","AStr",str,"Cdecl " "Int")
}

Posted: Mon Jul 22, 2013 7:48 am
by tzuk
DR_LaRRY_PEpPeR here are my results:

OPEN NEW NORMAL WINDOW

Normal Firefox - Window took 0.022 seconds to open
Sandbox Firefox - Window took 0.024 seconds to open.

OPEN NEW POP UP WINDOW

Normal Firefox - Window took 0.078 seconds to open
Sandbox Firefox - Window took 0.088 seconds to open.

What I've been trying to say throughout our discussion on the performance issue is that
I'm not going to be able to identify where a difference of 0.002s or even 0.01s is coming
from, it's just not enough of a difference. If you can figure out which component on your
system is responsible for causing the slowdown, then I will look into it. Otherwise there
isn't anything that I can do.

Posted: Mon Jul 22, 2013 1:00 pm
by DR_LaRRY_PEpPeR
Sorry I didn't reply sooner... Was hardly around yesterday, and I wanted to check something else first.

Firefox? Yeah, the "Normal Window" won't show any difference as long as it's opened in a tab -- I just included Normal and Pop-up for situations where each behaves/performs differently. :) AND, I didn't mention it, but I'm actually NOT seeing any real difference either on the laptop system with Firefox opening actual windows -- although there is a difference in full launch times (numbers below).

I'd say forget Firefox -- no issues there that don't also affect IE, and a lot worse. I just mentioned it since I wanted users to be able to check any browser. Although on my main system, as I said, I see a similar pattern with Firefox, but the absolute numbers are just much lower... But I'm looking at relative differences between settings.

I know, tzuk, that's why I'm trying to give you the best info I can. :) I was hoping with these specific window classes I identified, you could make something of them, and be able to see more of a difference than a couple hundredths. :D

I just gathered numbers again (at end), which I hadn't done this time (just noted in my head key relative differences I posted). I had already done the * (global vs prefix), $:explorer.exe numbers thing, and you said you didn't see anything like the differences I reported (I was wondering how MANY systems you checked with?). So I'm glad I was able to find these specifics in case the previous stuff was too broad/vague, etc...
tzuk wrote:Still on that issue I see. Thanks for your work. I'm not sure I understand in what way you're seeing that those window classes are a problem. Can you give an example, say for SysPager, what do you see that happens with it?
Yeah, but I hadn't checked or done anything in awhile, just wondering about it and living with it. :) Just last week, I decided to try checking again with A* ... Z* window classes (close enough to * without using that "special" setting). Then I used a prefix with A* ... Z* and finally saw that that way, the prefix makes no difference. :P 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... :shock:

Anyway, I'm saying that those classes are a "problem" because of their slowdown, that's the problem they cause. :) You can see what SysPager's impact is on the main system below. On the laptop, I see it's actually Tooltips_class32 that's the worst, like Windows 7.

So, you don't recognize anything "special," certain characteristics or anything with those classes? I wondered if you might say that X classes are processed in Y way, for Z reason. :)

It just seems to me that those classes are always being "processed" slowly or such, even just in the sandbox with defaults. Then it gets worse when Sandboxie "sees" those particular classes outside the sandbox as well (in Explorer, et al.)... Why is that?

I ASSUME that these classes are actually X amount slower per "use," and not just "used" X amount more often.

Question: Regarding PerformanceTest's 2D Windows Interface benchmark -- that IS affected by OpenWinClass settings the same as anything else, right? Seems like good news that it's not degraded at all by sandboxing, even with the usually-slowest * (prefix) setting. I think any program that uses "problem-free" classes would perform the same?


My numbers follow. Remember, there's basically nothing installed on the Windows 7 system (only a couple windows open) and absolutely nothing installed on laptop. So I'd think my minimum differences could be reproduced with IE. Also, things get WORSE the more windows and "stuff" that's open. Main system sandbox has been active for 11 days, and I just have my usual few windows open (same for all tests). If stuff was closed (and sandbox "fresh?") it'd be a bit better (I'd say ~2/3 of worst times).

All window opening times, except Firefox on laptop.
XP laptop
IE 6
0.15 - UNsandboxed
0.23 - * (Global)
0.30 - Default settings
0.38 - Tooltips_class32
0.45 - Problem classes OR $:explorer.exe
0.64 - * (Prefix)

Firefox (Full launch time in active sandbox)
0.61 - UNsandboxed
0.76 - * (Global)
0.81 - Default settings
0.88 - Problem classes OR $:explorer.exe
0.96 - * (Prefix)


64-bit 7, 32-bit IE 8
0.38 - UNsandboxed
0.50 - * (Global)
0.78 - Default settings
1.07 - Tooltips_class32
1.55 - $:explorer.exe
1.64 - Problem classes
2.20 - * (Prefix)


XP main
IE 6
0.10 - UNsandboxed
0.20 - * (Global)
0.70 - Default settings
2.30 - SysPager
3.25 - $:explorer.exe
4.10 - Problem classes
4.90 - * (Prefix)

Firefox
0.09 - UNsandboxed
0.11 - * (Global)
0.13 - Default settings
0.18 - SysPager
0.25 - $:explorer.exe
0.29 - Problem classes
0.32 - * (Prefix)



BTW: So you know, when IE is the slowest there, the main SbieSvc process uses ~4s of CPU time and GuiProxy uses ~1s. That must be MILLIONS of instructions. Doing what? I wish I knew!

Posted: Tue Jul 23, 2013 3:30 am
by tzuk
Results for IE:

OPEN NEW NORMAL WINDOW

Normal IE - Window took 0.04 seconds to open
Sandbox Firefox - Window took 0.11 seconds to open

OPEN NEW POP UP WINDOW

Normal IE - Window took 0.03 seconds to open
Sandbox IE - Window took 0.101 seconds to open.

Now, can we finally put this topic to rest, until you are able to identify what software component
or Windows setting or whatever in your computer is causing Sandboxie to behave this way?

Posted: Tue Jul 23, 2013 6:20 am
by DR_LaRRY_PEpPeR
You seem to be ignoring, among other things, what I posted about classes? :( (And again, no need to post "Normal" and "Pop-up" results -- if there's no difference, they're the same. ;))

What are your results with IE using OpenWinClass settings, at least, of * (global), defaults (I assume what you posted), the problem classes I mentioned, and * (prefix)? I hardly care about normal UNsandboxed results, FYI...

You keep talking about a software component or Windows settings on my computer (you mean computers, plural, since every system follows the same pattern). I've told you I don't see any software on main system that has an effect, and in general I don't like most software (of anything, but especially "security"), so that should tell you something about what I'll install or not. :) And I PROMISE there's no other software component or changed Windows settings on the other 2 systems! Defaults, defaults, defaults...

I said when IE is taking 4-5s to open a window in the slowest scenario, Sandboxie's SbieSvc processes use ~5s of CPU time between them (4s + 1s for GuiProxy). THAT is Sandboxie doing something, no? Not another "software component?" Want to see the loaded DLLs again? SbieSvc; and GuiProxy (4 months ago, 4.01.04, but it's the same now when I compared).

Standard expected stuff, right...? (Any wrong versions?) So what is Sandboxie doing while I'm waiting for a window?


What I was thinking about earlier is, perhaps there's an inefficient way Sandboxie is checking/comparing class names...? It seems like that would make sense in most of the cases I'm seeing (not sure about all). Meaning that, maybe there's not a problem with a specific class in itself, but when there are SO many of them (like "exposing" TONS of BaseBar and SysPager in Explorer), some operation in Sandboxie is taking a proportional amount of time for however many instances exist of a given class? Like O(n) or O(n log n) when it should be just about constant...

I don't really know much about messing with windowing-related function calls, but I might attempt to rig up some kind of program to check or do "something" (???) to a certain class or window handle and see if I can notice any other specific differences... :?


Other info I feel is being ignored... Look what I just checked quick on laptop IE:

Default settings
0.30 - 1 IE window (as I posted)
0.34 - 10 extra UNsandboxed IE windows
0.42 - 10 extra sandboxed IE windows

* (prefix)
0.64 - 1 IE window (as I posted)
0.70 - 10 extra sandboxed IE windows
1.30 - 10 extra UNsandboxed IE windows


Yes, those numbers are right (reversed with extra windows). This seems to support my idea about inefficient class checking/comparing... *shrug* Just a very simple case, but like I said, things get worse and worse the more windows and "stuff" that's open (sheer number of "window objects?").

Why, why, WHY? This also seems like it could be the case where other users are reporting/showing much worse general usage performance than I'm seeing.


Frustrating, when I've given way more details than an average user... :) What else? Resource Access Monitor logs? Just more of the usual standard stuff!

Posted: Tue Jul 23, 2013 7:28 am
by tzuk
Yes, I understand that SbieSvc processes are doing more stuff, and this clearly has something to do with the performance problems that you are seeing. What I am saying is we don't know yet what is the unique something in your computers that is causing the SbieSvc processes to do more stuff. This point has been at the heart of this topic for a few months now.

Whatever performance problems you can imagine in Sandboxie code (like the inefficient way Sandboxie is checking/comparing class names), the question is still this: Why do only you and a few others see these performance problems? What is different in your computers that is causing GUI-related code in Sandboxie to do all this extra work?

Posted: Tue Jul 23, 2013 12:28 pm
by DR_LaRRY_PEpPeR
Short reply this time... :)

Can you post results for some non-default OpenWinClass settings like I asked...? I'm really curious to see your times. :D I mean, using the "problem" classes I mentioned and/or * (global) vs * (prefix).

Maybe on Windows 7 with IE whichever? (I still have no idea if you've only checked on 1 config/system or what...)



BTW, I may have some different new information coming -- e.g. very isolated detail. :o Still checking, and not sure what to make of it, or how it fits in with other results... :?

Posted: Wed Jul 24, 2013 4:52 am
by tzuk
on a second system I am seeing results of ~200 for IE outside the sandbox,

~250-300 for IE in a sandbox with OpenWinClass=*,

and ~600 for IE in a sandbox with default settings.

Posted: Wed Jul 24, 2013 7:41 am
by BUCKAROO
If it isn't already known, 3.76 doesn't see this overall impact by a factor upwards of ~2~ to window operations, what operations specifically is not known, yet, it all adds up.

For what it's worth though, I had to call RegisterClassEx TEN THOUSAND times to notice this doubling (2 secs =* vs. 4 secs =) present in the one WinAPI function I tested.

I presume you can't easily add an optional setting to switch code path between window object string(?) matching to ATOM|HANDLE lookup concept (to ID BOXED windows?) and drop "All interactions with window objects outside the sandbox", if that's even the bottleneck ? I have little to none good insight here as to the internal cause of the slowdown, neither am I in any position to make better suggestions to the design of your program. :-)

I think this is just the reality of the new implementation, I don't mind. Sandboxie has always been and continues to be elegant in its design and usability despite the efficiency decrease in Sbie 4 to window heavy sandboxed applications and their GUI responsiveness at busiest trigger times.

Posted: Tue Jul 30, 2013 1:00 pm
by DR_LaRRY_PEpPeR
BUCKAROO, thanks for posting the BenchmarkIE stuff above -- I didn't try to fully understand the script, but the results show the same pattern. :) And about RegisterClassEx: I checked after your post and didn't see much difference there -- maybe the difference was double also, except 10,000 calls only took some fraction of a second. ;) (In C, maybe you were using AutoHotkey...) I didn't check on 3.76, but of course there will be some small necessary slowdown with certain functions -- I was just trying to determine WHAT specifically was so much slower in v4. I doubt it's registering classes, since there aren't that many (??) and I don't think that happens much after startup, etc...


tzuk, after your second-to-last post, I fired up the compiler to start looking more closely for some cause -- within 5 mins I knew I found something (what I referred to in my last post) when I just picked IsWindowVisible and did 100 million calls in 3s unsandboxed, but sandboxed it wasn't done 45m later (it would've taken hours!). More on this later... (Although it's not as big a deal as I thought it was, or could be... after my weekend findings!)

Also, those IE results are like the pattern I see (and * (prefix) should be slowest, of course), and different than previous posted results. BTW, GuiProxy is still never, ever a factor with anything I've seen (seems like good news as I said), then or now (before or after 4.03.01).


Anyway, a bit later I'll post my findings and an example benchmark program for others to check with. :) Some "shocking" performance results, findings, problem area(s), etc. :shock: Very specific now where it seems the slowness is coming from (and yes, affected by weird stuff like those "problem" classes), hence the isolated test program.

Check back in about 10 hours! :D

Posted: Tue Jul 30, 2013 2:45 pm
by BUCKAROO
DR_LaRRY_PEpPeR wrote:(In C, maybe you were using AutoHotkey...)
AutoHotkey tidbit: One can get improved ahk script performance with use of SetBatchLines -1 to restrict AutoHotkey (on the C side) entering its Windows Message processing loop too often. Limiting it to a Sleep -1 command (not a guarantee AutoHotkey won't enter its loop and PeekMessage for certain other commands).
DR_LaRRY_PEpPeR wrote:I doubt it's registering classes, since there aren't that many (??) and I don't think that happens much after startup, etc...
You're absolutely right, of course, it has been examined at the least. Applications register only one to half a dozen at startup. Testing significantly longer szClassNames while the time taken increased, unsurprisingly, but contrary to initial finding, served to narrow the divide.

I didn't check 3.76 with (now eliminated) RegisterClassEx either or with the advent of astonishing results via IsWindowVisible. :shock:
IsWindowVisible 10,000 times wrote:"C:\Program Files\Sandboxie\SbieIni.exe" set BenchmarkIE Enabled y
(ExitCode 0)
[BenchmarkIE] BenchmarkIsWindowVisible
[BenchmarkIE] OpenWinClass=
2403 ms
2403 ms
2340 ms
[BenchmarkIE] finished. Waited 9.188 seconds.
[BenchmarkIE] BenchmarkIsWindowVisible
[BenchmarkIE] OpenWinClass=*
0 ms
16 ms
15 ms
[BenchmarkIE] finished. Waited 1.654 seconds.
Choice function call, DR_LaRRY_PEpPeR ! :)

Relevant BenchmarkIE test: (Do-It-Yourself patch.)

Code: Select all

	else if param3 contains BenchmarkIsWindowVisible
	{
		hWnd:=WinExist("ahk_class Shell_TrayWnd")
		SetBatchLines,-1
		Loop,3
		{
			StartTime:=A_TickCount
			Loop,10000
			{
				DllCall("IsWindowVisible","UPtr",hWnd)
			}
			ElapsedTime:=A_TickCount-StartTime
			Console("ECHO	" ElapsedTime " ms")
		}
	}

Code: Select all

Gui,1:Add,Button,W300 GBenchmarkIsWindowVisible,Benchmark IsWindowVisible

Code: Select all

BenchmarkIsWindowVisible:
Benchmark(A_ThisLabel)
return

Posted: Tue Jul 30, 2013 11:00 pm
by DR_LaRRY_PEpPeR
Yeah, accessing a non-sandboxed handle (Shell_TrayWnd), or attempting to, whether it's valid or not, is MUCH slower than a sandboxed handle (which also has some slowdown), but I don't think that's as much of a factor as I initially thought...


Anyway, here are my findings, with the example benchmark program at the end. :shock:

First, the accessing of window handles/objects (my initial testing)... Other functions besides IsWindowVisible that operate on a handle seem to be the same. 3.76 has NO impact on those operations at all. On version 4, the overhead for accessing sandboxed handles is about 24x higher (40x I think on main XP system). For UNsandboxed handles (valid outside sandbox, inaccessible, or bogus (0) doesn't matter), it's 95-200x higher than that: e.g. over 2,000x more overhead than unsandboxed or 3.76! (It's nearly 5,000x slower on main system.) This would apply to out-of-sandbox access attempts, of course, which I thought IE might be doing more of... Window class settings/names have no effect (besides global * ...NOW).

I created a GUI benchmark (never made any GUI thing besides a blank test window :P :oops:), 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=* :o So didn't want to post yet until I figured out more (although the window access performance is still something :)), because we users KNOW in 4.02 and before that OpenWinClass=* speeds things up, but which OTHER "thing" is responsible?

Obviously the OpenWinClass=* change in 4.03.01 is responsible for removing the access overhead, but it seems too much with any other setting (especially non-sandbox).

FYI: When accessing UNsandboxed handles, that's when there's major CPU usage from the SbieSvc process(es). Same whether accessible (Open) or not. No SbieSvc CPU with sandboxed handles (IIRC 4.02 also), even though 24-40x overhead.


So to try to find what ELSE is affected (differently) by OpenWinClass, I decided to start/run stuff with API Monitor for the first time since last year. (WOW is it slow/laggy in Sandboxie 4!) Looking for functions whose call times are greatly affected by OpenWinClass... This took awhile, longer than it should have (remember, I hardly know what I'm doing). What should I have checked/noticed sooner?! CreateWindow(Ex)! :shock: Looked like a BIG impact there, which I started checking on its own and added it to the GUIBench program.

It doesn't seem to matter whether it's a custom class or a simple static control, results are the same. In the quick checking I did, my resource-based Dialog doesn't seem to be slowed down, it's just the actual CreateWindow type functions.

Check out these window creation results!

NO overhead/slowdown with OpenWinClass=* in 3.76, 4.02, or 4.04+ (bingo, found the speedup that applies to 4.02!)

125x slower with 3.76 (only checked on clean XP laptop). Besides global *, window settings make no difference.

At LEAST 800x slower with v4 default settings (XP and 64-bit 7), so 6x slower than 3.76 at best. It's about 8,000x slower now on my main XP, give or take. Is this where having more windows and "stuff" running makes it slower?

Adding just OpenWinClass=Tooltips_class32 makes it a few times worse, e.g. at least 2,500x slower overall (or 20,000x on main system). I didn't check other classes besides a couple "problem" ones I posted, but see, this unrelated stuff is affecting creation of a static control window in the test?!

Using * (prefix) makes it at least 10 times worse! Overall: Minimum 10,000x (XP laptop), 16,000x (64-bit 7), or over 120,000x slower (XP main)! Yes, can easily create 10 million windows at "full speed" in less time than 100 windows take with OpenWinClass=GUIBench.exe,* on main system. :cry:

Needless to say, major Sandboxie CPU usage!


It would be cool if others can check their system(s). :) Program(s) download: GUIBench.zip I included the initial CLI HwndBench (for checking arbitrary handle access; run for Usage), but you probably just want GUIBench (Screenshot). :)

To see what's happening: HwndBench source, GUIBench main source, and full GUIBench package (for building).

Posted: Wed Jul 31, 2013 11:23 am
by Peter2150
I have to agree with Tzuk. I haven't seen any change in performance on any of my 4 machines. GRanted they still are XP, and I mainly use Firefox. I don't know what the bench test might show, but frankly, it isn't worth my time to bother with them.

Pete