Speed up Task List Switching Topic is solved

[fitnerd]

Thank you for your detailed response and your tips, Dan! I will follow up on those and post more info as it becomes available. As a side question, is there a way to specify a specific log file path with "-g" option in the command line, so that different instances will use different logs?

Just to be crystal clear, this is TDL's initial startup time from the moment of double-clicking ToDoList.exe?

Yes, those times are from the moment I click on the shortcut to launch the program.

[abstr]

>> As a side question, is there a way to specify a specific log file path with "-g" option in the command line, so that different instances will use different logs?

Not currently.

[fitnerd]

Got around finally to using GDIView as you suggested.

Here's the initial snapshot after most TDLs have been running for a week.

TDL's GDI handles by far exceed anything else on the computer. The closest was Explorer.exe with ~700. But all TDLs are at least 3 times that, and on average consume at least an order of magnitude more GDI handles than other GDI-based processes. I will see how it behaves tomorrow and a few days later to see if the counts go up and by how much.

I will also post the logs as you requested in the near future.

[abstr]

After further analysis I agree with you that there is one or more resource leaks occurring.

What's tricky is that the tool I'm using for analysis is currently suggesting that the leaks are occurring inside of Windows system dlls which is why I've been ignoring them to date as being not fixable.

However, it's still feasible that something in my code could be causing the system dlls to leak so I'm going to try two approaches:

1. Create a sample app that causes the same leaks to simplify the investigation - no luck so far - it's probably not a trivial interaction between components.
2. Rework my components whose calls into the system dlls are triggering the leaks - going to try this tonight.

ps. Could you also possibly do a 'quick' test for me:

1. Install TDL 7.2 to a new location
2. Run TDL so it opens with 'Introduction.tdl'
3. Run GDIView
4. Right-click on ToDoList.exe > Save Selected Items
5. Post it here

Just hoping that the leak is consistent/reproducible.

[fitnerd]

Thank you for continuing to look into this.

Here are the results you requested:

Code: Select all

==================================================
Process ID        : 27916
Process Name      : ToDoList.exe
Process Path      : C:\TDL\ToDoList.exe
Process User      : MAINPC\George
Pen               : 0
ExtPen            : 0
Brush             : 2
Bitmap            : 3
Font              : 3
Palette           : 0
Region            : 1
DC                : 8
Metafile DC       : 0
Enhanced metafile DC: 0
Other GDI         : 0
GDI Total         : 0
All GDI           : 559
==================================================

I guess it has a lot less GDI handles because only Introduction.tdl was loaded. In the screenshot I posted all instances had at least 1 or 2 tdls loaded and 5-10 "delayed".

I also had to restart my computer 2 days ago, and did run GDIView again on this fresh system, after having loaded all 12 TDL instances (each having loaded just the first task list). The results were very similar to the screenshot I posted: all instances had way in excess of 1000 handles, some as many as 3700, and that is with a fresh start and only one task list actually loaded.

Could it be that it's not just the GDI objects that are leaking, but User objects too, like hwnds or whatever other resources Win32 API uses to handle the UI? Is there a similar tool to monitor those?