Slowdown after repeated executions

[k6dgw]

This is an observation. It is not a request for a fix. After quite a bit of testing on three different machines [1-2.8 GHz Intel dual core with 8 GB RAM, 2-3.2 GHz Intel i5 quad core with 16 GB RAM, 3-3.1 GHz AMD quad core with 16 GB RAM/1 TB SDD] I've found that LBB programs [either compiled to a .exe or executed from the IDE] when run repeatedly, will slow down:

1. File dialogs take longer and longer to paint

2. Windows [in general] take longer and longer to paint ... some a little longer, some much longer.

I don't see this effect on computation-bound programs [satellite ephemeris generator] or file intensive applications. Other Windows apps [i.e. not LBB] are not affected. Restarting Windows reverts to normal speeds initially which then begin to generate delays with repeated LBB executions. When an LBB program terminates, Task Manager shows no processes left that could be linked to LBB.

Unfortunately, I've become accustomed to utilizing many of the LBB extensions/fixes to LB4, and none of my creations will run on LB4 or I'd try that out. I normally work on the AMD machine and restarts are common. As I said, FYI, observation only.

[guest]

1. File dialogs take longer and longer to paint
2. Windows [in general] take longer and longer to paint ... some a little longer, some much longer.

Please list a (small, but complete and self-contained) program which illustrates the behavior, along with instructions for how to run it (if needed). This will allow other people to reproduce the issue - or not - and this will provide valuable information on the possible cause.

The rules for when Windows decides to paint a window are complicated, and I think have changed between versions of Windows. It's possible to force a window to be painted 'now' but generally that isn't recommended. The only time LBB does that is in a WAIT statement, when the currently 'active' window is sent an UpdateWindow message.

File dialogs specifically are, of course, entirely generated and painted by Windows. LBB simply calls the GetOpenFileName() or GetSaveFileName() API function and waits for it to return, so it has no control over when the dialog window is painted.

[k6dgw]

OK, stand by ... this may take a couple of days, my current project is around 11,000 LOC. Skip

[JackKelly]

I don't know if it's related or not but lately LBB takes 40 seconds to load and run on my laptop. I can't say for sure when this started. Maybe after a Windows 10 update. Is anyone else experiencing this?

[guest]

I don't know if it's related or not but lately LBB takes 40 seconds to load and run on my laptop.

It's less than two seconds here, which is what I would expect. The first thing I would try is disabling your Anti-Virus tools, which can sometimes be responsible for that kind of problem. If that makes no difference, what does Task Manager say is happening during the long delay?

[k6dgw]

Coming up with an example that duplicates my observation in less than 11K LOC is proving to be difficult. My first example [which did not duplicate the observation] was just a series of simple windows with a few controls each that opened and closed each other. No joy there, but it does suggest that slowly opening windows may be an effect but is not the root cause. I'll keep looking for a way to recreate it.

For Jack Kelly: I've noticed the slowness in starting of late also. I think I can peg it to "Microsoft Tuesday" three weeks ago when a particularly lengthy Windows update descended. It has since gone away ... I think.

[k6dgw]

Well, a little progress. The slowdown on successive executions appears to occur only when in repeated code-compile-execute sequences. I created an executable and I don't see the slowdown, at least in maybe 15-20 executions. That number of compile-execute would have been a very noticeable. FWIW: Task Mangler reports:

16 GB memory
4.9 GB used / 0 GB compressed
9.7 GB available

6.2/17.2 committed
5.8 GB cached

556 MB paged pool
345 MB non-paged pool

Skip K6DGW

[guest]

The slowdown on successive executions appears to occur only when in repeated code-compile-execute sequences. I created an executable and I don't see the slowdown, at least in maybe 15-20 executions.

OK. Although I don't have an explanation, I am less concerned if the problem manifests only in a 'development' environment.

[k6dgw]

More observation, FWIW:

1. I ran repeatedly from the IDE [compile/execute], way longer than I usually do without re-booting, and the window paint-time had gotten REALLY slow. I then executed from the .exe and ... it too was slow ... not nearly as slow as when being executed from the IDE, but very noticeable. A re-boot restored normal speed.

2. Other, non-LBB, programs also show extended paint times. Nowhere near as obvious as with the LBB IDE, and I have to induce the slowdown by running the LBB code from the IDE many many times, but it too is noticeable.

Just observations, not expecting any fix or new version.

Skip K6DGW

[guest]

A re-boot restored normal speed.

So does Task Manager show any evidence of a resource or memory leak (with additional columns enabled)? It's hard to understand what else could result in a slow-down that persists between different processes, but is resolved by a reboot.

If you can identify what kind of leak there is, it may be possible to guess the cause. Make sure that you check 'Handles', 'GDI Objects' and 'User Objects' in addition to the default set of columns.