VB6 performance (with youtube example) of Windows XP vs 10 and using of User Controls

[mark_leicester]

We have had a significant increase in customers complaining lately that their systems are running slow.
After investigating and ruling out the backend processes on the server we looked at the front end.
We found when running the front end on a Windows XP OS the app loads new forms around 5 time quicker than when running on Windows 10.
This 5 time quicker means that some screen that should take 2 seconds to load are taking 10 seconds. The users of the business-critical system are quite rightly not happy about this.

The front-end VB6 app was first created about 20 years ago and makes extensive use of “User Controls”.
Most User Controls contain a number of other controls in them, some of these being other “User Controls”
Some forms in the app can contain up to around 50 top level User Controls on them.
So taking into account the User Controls within User Controls this makes quite a large number of controls in total on some forms.
We think this is what’s triggering the problem and have made a standalone test app to try and prove this.

We’ve tried a lot of googling, and looking through this forum, but have so far not found anything that helps. Also not had any luck playing with DPI settings.
Therefore we thought we’d make this post and hoping this community can point us in the right direction if this is a known issue, or help investigate if not. However we are expecting this is not the first time someone has had this problem.

I’ll try and attached the standalone project here as a zip so others could reproduce these results.

I’ll also try adding a link to a youtube vid of this example program showing a screen with around 1000 users controls on it. (Our app does not have this many controls, but this large number helps highlight the issue)
https://youtu.be/xnaGDctNKPE




This vid shows Win XP running side-by-side with Win 10 and the performance of the same small example program running on both.
In the vid example a time is recorded before the form3.show() is called and another time is record when form_activate() exits. The final frame from the vid showing the results is posted below. The results are:
- Win XP = 6 seconds
- Win 10 = 56 seconds



If there is a silver bullet to get this app running quicker on Win10 then this will probably help us a lot.
Thanks for reading this far and help guidance greatly appreciated.

[DEXWERX]

AutoRedraw = False
HasDC = False
ClipControls = False

should give you at least a 4x speed boost.

edit:
Allocating that many DCs on windows is... I want to say ignorant, but who actually knows anything about Win32 internals these days. The glory days of Petzold are long gone.

I'm sure you probably already know the real solution is not to abuse the User Control in such a way. You've gone way past it's practical limits. Maybe post a screen of an actual use case, to elicit some redesign ideas.

Good luck!

[dilettante]

If you are going to throw an issue out there giving us little to go on but "Windows 10 vs Windows XP" it is hard to make many suggestions.

Did the problem also occur when running on Windows Vista? Windows 7? Windows 8? Windows 8.1? And which Windows 10? It has been undergoing significant changes since first released... you could say we're at Windows 12 or 14 right now in a sense except that Microsoft stopped incrementing the major version number for marketing purposes.

One obvious thing that happened post-XP was Desktop Composition. Depending on how these UserControls have been written that might have a major impact. But right now I'm not sure you have told us enough to suggest that UserControls are at the heart of the matter. For all we can tell there may be some expensive appcompat shims involved.

Depending on what is going on with client machine DPI settings DPI virtualization might have some impact. A simple thing here might be to be sure you are testing on a Windows 10 machine at 96 DPI.

We just don't know enough about your application. Without the source code of a test case that exhibits the problem I'm not sure what we can suggest outside of wild guesses.

[DataMiser]

So in this sample there are 572 user controls on the form and those user controls contain 5 controls each which means we have nearly 3000 controls on one form which IMO is way way to many. Not surprised that it is very slow. I loaded it and gave it a test run on my system under Windows 7 ~14 seconds to load. It also is very slow loading in the IDE. I tried changing the DPI to the default 96 as a test but no noticeable difference.

It may also be a good idea to tell us what PC(s) or VM(s) you are running these tests on as PC performance is part of the equation. In this case I tested it on a AMD P2 1100T 6 Core CPU 8gb ram running Windows 7 Pro

[DataMiser]

btw the test above was done from the IDE.

I tried the exe on my Windows 10 Machine. Ryzen 5 1600 16gb ram ~9 seconds
I tried the exe on the Windows 7 box ~13 seconds

I also tried the exe with the project open in VB6 on the Windows 7 machine ~ 130 seconds

[dilettante]

I guess I completely missed the attachment above. Mea culpa.

[Arnoutdv]

A slight speed increase by setting the Form3 WindowState to Minimized during design.
Add a Timer to Form3, with interval = 10
In the Timer event set the enabled property of the Timer to False, set the windowstate of the Form to Normal.

[DEXWERX]

Here's some timing numbers before/after setting
AutoRedraw = False
HasDC = False
ClipControls = False

WinXP:  6s --> 2s
Win 7: 14s --> 6s
Win10: 39s --> 9s

[DataMiser]

Interesting results. I wonder why it is 30% faster for me under Windows 10 than under Windows 7? My Windows 10 box is a stronger CPU with more cores but VB6 doesn't use the extra cores and the CPU speed is about the same on both. Could it be related to the hard drive speed? Maybe Vb creating tmp files or something like that. Windows 7 box has a mechanical HDD where the Windows 10 box uses a M2 Ultra SSD that is about 10-30 times faster than mechanical HDD

[DEXWERX]

I actually don't have a good win10 system handy, just a non-updated VM.
I bet an updated system would fair better, so YMMV.

Interesting thought about the SSD!

@OP --> https://docs.microsoft.com/en-us/pre...512(v%3dvs.60)
...although it doesn't seem to mention anything about Device Context resources.

[Shaggy Hiker]

Unfortunately, I had to delete the attachment as it contained compiled code (the exe, at the very least), which this site does not allow because we can't vouch for the safety. Please remove the compiled parts and re-attach. Anybody who needs the exe can re-compile from the source.

[mark_leicester]

Hi all,
Thanks for the really quick and informative responses!


To try and answer some of the questions so far…

@DEXWERX – Thanks for the suggestions and comments. Indeed the test app was to try and highlight what we thought was the problem with our app. To use that many controls in a production app could well be classed as ignorant. Really appreciate the time you must have spent on this running the test app in the different windows version!

@dilettante – Thanks for the comments. It is hard to state when the problem first started occurring. We did not really receive feedback like this until recently which is why we focused in on Win 10. However it could well be that this app started slowing down over the years with different windows version. If it would provide useful information we could potentially run our app in the different windows versions on the same vm host. This however would take time to achieve but could be done if the resulting information would be of value.

@DataMiser - Thanks for trying the app and question. The video and screenshot had the information in your asking for. However youtube and this site both reduced the quality so that you cannot really read this anymore. The VM Ware was sitting on the same machine as the one running directly in Win 10. For specs see the latest vid.

@Arnoutdv – Thanks, we need all the speed increases we can get.

@Shaggy Hiker - Apologies for including the .exe in the zip. I’ll try and re-upload now without this.





I can confirm for us adding the below makes the test app run significantly quicker:

AutoRedraw = False
HasDC = False
ClipControls = False

However, when we add these into our own app the speed increase in the problem forms’ loading time is around only 10% better.
So it helps a little. But we still have the problem.

I’ve put a new video of the app and a problem screen loading time. However, I have had to remove the screen text to prevent identity. Also I think it would be unlikely that the company would consent to publishing the code for this on-line.

See below the screen loading:
https://youtu.be/fB7mTjU14n4 (The pic quality is better directly on Youtube and not on here)



There are around 130 User Controls on this screen. These have the suggested settings from this site applied.
The button to show the screen it pressed when the timer in the bottom left cycles pasty 00.

In Windows XP in VM Ware running on the same machine this screen takes around 2 seconds to load.
Directly in Windows 10 this takes the 11 seconds.
What else could be the cause of this(??)

If we are close to exhausting the suggestions for quick setting changes then are there any (re)design ideas / consents that might help.

Thanks for all the help so far guys, really appreciate it!!

[wqweto]

What else could be the cause of this(??)

Loading of comboboxes can usually spin out of control if one (or more) of the lists grows disproportionately.

cheers,
</wqw>

[Elroy]

Hi Mark,

First of all, welcome to VBForums.

Secondly, I'd like to throw out a "thank you" for this. My primary project has about a dozen custom user controls, and I've got a few different forms (with the SSTab control) where quite a few of them are used. At the bottom, I attached a picture that gives an example. That orange area is an expanded UC that allows for a slider to be used to specify degrees. And, just as an FYI, yes, I have always made extensive use of control arrays. I'm not sure that form would be possible without them.

I'm not sure I'm abusing UCs as bad as your example, but I do use them frequently.

I'd never thought to turn off the HasDC and ClipControls on these things. And I certainly don't need them, as I'm never using their form's background for anything. I just went through and turned off the HasDC and ClipControls, and these forms are loading noticeably faster.

I suppose a thanks goes out to Dex as well, for providing the answer.

Never too late to learn a helpful tip.

Y'all Take Care,
Elroy

[wqweto]

Btw, just tested vbformtest - original on native Win10 and XP under VirtualBox -- same performance (within 1-2 seconds).

Could be that Hyper-V video drivers are making optimizations (skipping althogether) of some GDI calls.

cheers,
</wqw>

[mark_leicester]

Btw, just tested vbformtest - original on native Win10 and XP under VirtualBox -- same performance (within 1-2 seconds).

Hi wqweto,
Just to clear up any ambiguity. Can you confirm if your tests are returning with 1-2 seconds of each other, or 1-2 seconds in total? I think the first option.

We have tried Win10 (32) in Hyper-V and the results for us are the same as native Win10.
So unable to explain your results of XP being slower for you than everyone else...


Elroy - No problem. Glad others have benefited from this too.

[wqweto]

Win10 native vs XP virtual machine (guest OS in VirtualBox on same Win10 host OS) have the same performance here (within 1-2 seconds difference).

cheers,
</wqw>

[Jimboat]

AutoRedraw = False
HasDC = False
ClipControls = False
should give you at least a 4x speed boost.

Great info in this thread.
Question: is the switching of HasDC and ClipControls intended for the 2nd Form? or for every control on the 2nd Form?

[flyguille]

As any VB program runs in single thread single process, it is limited to what can do the faster single core.

I manage projects that were done back in XP era, through win 7, win 8, and win10, and it was already tested in win 11, no major change in speed that is USER EYE NOTICEABLE.

Ofcourse there will be differences if the GUI is doing real time DPI resizing if the monitor is not normal FULLHD, a large 2K or 4K monitor which does 125% or 150% scale up, will handle lots more pixels in the windows surface.

A native VB6 that is not declared DPI aware, will just SCALE up with AA the whole window, going it to be blurry , noticeable, not pixel perfect.

If the VB6 is declared DPI aware, and is properly programmed, the usercontrol will works in TWIPS scale, WORST CASE SCENARIO (BAD PROGRAMMING in UserControl) if it is executing some PSET/POINT ir LINE -(x,y) function to draw some graph, and the FOR NEXT expect going from pixel to pixel in walking in some axis, it will do the same pixel 15 times, or more, and that happens, when before was set all in PIXEL Scale, but doing DPI aware it was changed to all TWIPS scale, but forgot to include in the FOR NEXT the "STEP screen.twipsperpixelX" (by example).

WORST CASE SCENEARIO not related to DPI awareness. It is not drawing on objects or windows buffers. Like, not setting Form.AutoRedraw = true, not doing the UserControl or Form autoredraw = true, that will mean that in every single DRAWING function, it will go the FULL PATH right to the graphics card vram , in every single drawing function, object load spawn, part of the object spawn. And if it was uncover/cover again areas, too, it will call the full _refresh VB code again , and if there is controls overlapping, GOD save you!.



Bigger monitors dpi scale up, also means, that if in the user controls are doing something, like rendering stuff, the pixels count will be higher, so, also the GFX function will take longer.

I imagine that at O.S. level, the GUI has more overhead than just WinXP, the original, but IIRC WinXP SP3 with the transparency support, already has the GDI+ libraries like WinVistas.

[Jimboat]

I can confirm for us adding the below makes the test app run significantly quicker:

AutoRedraw = False
HasDC = False
ClipControls = False

Great info in this thread.
i have a question: is the switching (False) of HasDC and ClipControls intended for the 2nd Form? or for every control on the 2nd Form?

[baka]

its time to update the source.
I mean, u only need to "fix" the visual part.
yes, u can't do it in 2 seconds, it will take some time.
I would replace everything that is that old with newer solutions.
and also, avoid using "Load", find another way to show stuff.
one good way of coding is:
- how much can be prepare "before"
I have a game that loads a "data" file. but that data is created by a tool called "builder.exe" where it will sort and optimize everything.
so when my game is loading the "data" file I don't need to process anything.
the data contains tons of stuff. string.table, numeric-lists, mp3-data etc.
when dealing with hdc (u already got a hint, using refresh) its the same.

also I use binary load when loading "big" data. and the data is processed into UDT "after", not "while".
that will also speed things up. so don't load "UDT" at all (if u are doing that)

how much can be "premade", can U use memoryDC so u can use bitblt/alphablend to draw pictures (that can also be used to create the table)
even "input-boxes" can be converted into pure-drawing. yes. its a different approach, but it will remove the need of textbox/controls.

the visual part is important when dealing with a lot of things. that need to be optimized or u get issues like this.
the "cpu-usage" should not be about the visual but the calculation/process u do. if the visual is the culprit u need to find another way.
using bitblt u can have 500 frames per second. yes, its superfast. and also show the power of it.

so thats how u should code. always have in mind "optimization/speed"