Faster when 'run as administrator'

[HughLerwill]

As touched upon in thread222-1695412 I am finding the following code runs significantly faster (ide and exe) under Win 7 64 bit when 'run as administrator'

Option Explicit

Private Declare Function QueryPerformanceFrequency Lib "kernel32" (lpFrequency As Currency) As Long
Private Declare Function QueryPerformanceCounter Lib "kernel32" (lpPerformanceCount As Currency) As Long

Private Sub Command1_Click()

    Dim i&, j&, QPTicks As Currency, QPTicks2 As Currency, QPfreq As Currency
    'List1 is set unsorted at design time
    
    QueryPerformanceFrequency QPfreq
    
    List1.Visible = False
    QueryPerformanceCounter QPTicks
    For j = 1 To 100
        List1.Clear
        For i = 1 To 1000
                List1.AddItem CStr(i)
        Next
    Next
    QueryPerformanceCounter QPTicks2
    List1.Visible = True
    
    MsgBox j - 1 & "*" & List1.ListCount & " Items in " & (QPTicks2 - QPTicks) / QPfreq & " seconds"
    
End Sub

Any explanation and/ or fix to make it faster when not 'run as administrator' would be appreciated.

 

[dilettante]

I retested on 4 different machines and can't find any such difference.

Vista SP2 32-bit
Vista SP2 64-bit
Win7 SP1 32-bit
WHS 2011 SP1 64-bit

 

[HughLerwill]

dil.. thanks for that; good news.

Can anyone give comments re a test on Win7 64 bit; my tests have been on Win7 Ultimate 64 bit, SP1 so far.

 

[strongm]

>a test on Win7 64 bit

Dilettante already has. WHS 2011 is essentially Windows Server 2008 R2

 

[HughLerwill]

strongm thanks, I guess it is a quirk on my system then.

 

[HughLerwill]

I will quit with this post unless anyone else finds this thread interesting however;
dilettante - your comment ending ..
>...Aero performance?
Got me wondering about influence of display settings on the timings. Previously my tests were all done using a Win7 basic theme (ie. non Aero).
Speed is a little worse with Aero enabled, but consderably better when the Windows Classic theme is selected. In all cases speed is best in the exe when Disable visual themes has been ticked in Compatibility settings for the app. In all cases running as admin still seems to give a advantage although it is marginal in the faster timings.
I wonder what kind of display settings you were using during your tests.

 

[dilettante]

I did most of my testing with Aero enabled, but I was using Classic Windows on WHS.

I went back again, logged on as a user defaulting to the ugly, washed-out Win7 style Aero theme. Ran the test again with Aero both as a standard user and elevated (over the shoulder credentials of an admin user0 within the session. Same timing each way.

BUT:

Incredibly enough, it takes about 10 times as long, either as a standard user or elevated!

Turned off Aero and sure enough the times came back to the expected range.


I think you might be onto something here.

I can't test further right now because after turning off Aero it won't let me turn it back on, probably because I was RDP-ing into the box. I'll have to go connect a KVM and physically log into the server to change back I guess.

 

[HughLerwill]

dilettante - thanks very much for doing that, although our results re 'run as admin' still seem to differ, I was begining to think I was imagining things.
Other stuff I've toyed with;
Changing the dpi setting from 120 to 96 seems to make no difference. I normally use 120dpi on a 1920*1200 display.
Running with a manifest to enable v6 controls seems to make no difference.

 

[dilettante]

The whopping 10x difference in timing floored me at first and I don't claim to understand it.


One thing that is notable about that particular machine though is that it runs with the standard VGA driver that comes in Windows. This is because Intel has dropped the ball, and doesn't offer a 64-bit video driver for the chipset on this Intel CPU/board combo. Because of that they don't rate the CPU (which has an on-die GPU) for use with any 64-bit OS.

If you can live with the standard VGA though it runs just great as a small 64-bit server. Hyperthreaded dual cores (4 execution units) and excellent performance.

The sad part is their 32-bit video drivers for Vista and Win7 don't even seem to work! I'm beginning to wonder if Intel isn't suffering the same internal infrastructure (i.e. core skills) decay that Microsoft suffers from.


As a result Aero in Win7/Server R2 struggles because it offloads even more work onto the GPU than Vista does. The funny part is Vista on the same machine with the VGA driver is smart enough to tell you that you can't run Aero. Since this driver can't use any of the hardware acceleration in the GPU... poor performance.

I'm still not sure how this causes the 10x slowdown of your test program but it's probably due to GDI calls made when updating even a Visible = False ListBox.

Retesting today shows the same results, so it wasn't a fluke.

 

[HughLerwill]

Just for information; here's the dirt on my Win7 box;
System
--------------------------------------------------------------------------------

Manufacturer Dell Inc.
Model Precision M4500
Total amount of system memory 8.00 GB RAM
System type 64-bit operating system
Number of processor cores 4

Graphics
--------------------------------------------------------------------------------

Display adapter type NVIDIA Quadro FX 1800M
Total available graphics memory 4607 MB
Dedicated graphics memory 1024 MB
Dedicated system memory 0 MB
Shared system memory 3583 MB
Display adapter driver version 8.17.12.6776
Primary monitor resolution 1920x1080
DirectX version DirectX 10

Win7 Performance index at the end of each line (out of a max possible of 7.9)
Processor Intel(R) Core(TM) i7 CPU Q 740 @ 1.73GHz 7.1
Memory (RAM) 8.00 GB 7.4
Graphics NVIDIA Quadro FX 1800M 6.6
Gaming graphics 4607 MB Total available graphics memory 6.6
Primary hard disk 302GB Free (454GB Total) 5.9

 

[dilettante]

Well in any case a ListBox control seems to be a fairly heavyweight object.

Just as a test I tried modifying your code to run the same tests using a VB6 Collection, which is often panned as performing poorly. Note that it has no analog of the ListBox.Clear method so another loop is required to emulate that part of your test.

Option Explicit

Private Declare Function QueryPerformanceFrequency Lib "kernel32" (lpFrequency As Currency) As Long
Private Declare Function QueryPerformanceCounter Lib "kernel32" (lpPerformanceCount As Currency) As Long

Private C As Collection

Private Sub Command1_Click()

    Dim i&, j&, QPTicks As Currency, QPTicks2 As Currency, QPfreq As Currency
    'List1 is set unsorted at design time
    
    QueryPerformanceFrequency QPfreq
    
    QueryPerformanceCounter QPTicks
    For j = 1 To 100
        Do Until C.Count = 0
            C.Remove C.Count
        Loop
        For i = 1 To 1000
                C.Add CStr(i)
        Next
    Next
    QueryPerformanceCounter QPTicks2
    
    MsgBox j - 1 & "*" & C.Count & " Items in " & (QPTicks2 - QPTicks) / QPfreq & " seconds"
    
End Sub

Private Sub Form_Load()
    Set C = New Collection
End Sub

This takes less than 1/20th of the time of your ListBox test case on one machine and under 1/3 the time on another machine. All of the "wild" differences occur when running Aero.

This leads me to the tentative conclusions:
[ul]
[li]Don't do anything intensive such as manual sorting or searching on a ListBox. Use a Collection, ADO Recordset, array, almost anything else.[/li]
[li]Visual controls such as ListBox are slowed down by Aero, sometimes considerably depending on video adapter hardware, drivers, and the current planetary alignments.[/li]
[/ul]

 

[HughLerwill]

dilettante - thanks. Yes I'd tried that myself (you may remember I was using a Collection to ensure unique enties in my List in the previous thread) and seemingly the lack of a visual component in a Collection makes it fly by comparison. Speed of the Collection is not quite so good when a Key is specified in the Add but is not affected by display settings.
On the other hand ComboBoxes (more visually complex) are even more sluggish than ListBoxes.
I'm wondering how a Windowless ListBox may perform but that means rummaging with my VB6 installation disks and I have'nt had the time yet.

 

[strongm]

>no analog of the ListBox.Clear method so another loop is required to emulate that

Or

Set C = New Collection

 

[dilettante]

> Set C = New Collection

A good solution when the Collection doesn't hold objects. An excellent point in any case.

 

[dilettante]

> I'm wondering how a Windowless ListBox may perform

A quick test shows... quite well actually, as good as a Collection if not better!

 

[strongm]

All very interesting. It suggests that the windowed controls may be spewing out GDI calls that the normal windows manager ignores (or more likely defers) but which the Desktop Windows Manager intercepts and tries to render into it's buffer whether it needs to or not.

>when the Collection doesn't hold objects

I'd argue it's fine even if it holds objects, unless it contains the last reference to an object that requires explicit teardown code (but that would effect the loop solution as well); resetting a Collection this way happily, legitimately and correctly decrements the reference count to any objects contained in the collection.

 

[dilettante]

I'd expect a Collection of objects to be as quickly destroyed oughtright as by manually removing each one first, but I'm almost sure that doesn't turn out to be true.

For all I know there isn't a difference until the Collection holds objects which in turn hold sub-Collections.

In any case I don't have a test suite to prove it, it's just recollection. Maybe somebody can find an existing study of that issue somewhere. Checking a few programs using nested Collections to build custom DOM-like hierarchies and such I find cases where I've done things both ways.

 

[HughLerwill]

>...quite well actually...
I rummaged and confirmed that today, thanks, it's snappy!