Speed up Task List Switching Topic is solved

[fitnerd]

Hi Dan!

For a very long time switching between opened task lists (whether delay-loaded or not) within a single TDL instance has been rather slow - from 3 to as long as 10 seconds just to show the list (even if it is already loaded, and even if it is rather small with no more than a few hundred items).

FYI - I have disabled other views and only using Tree View.

I also noticed the impressively LOW RAM usage of TDL. Even when it has 20 task lists open, each with a few hundred items, it still consumes no more than ~50MB. On the one hand this is great! But on the other hand, it provides an area for significant performance improvements via caching / relying more on memory instead of recomputing various values all the time.

So, perhaps you can more aggressively cache various things whenever possible, so as to significantly improve performance and rely less on CPU. I cannot speak for others, but I am certain that even if you were to quadruple the amount of RAM used, it will more than pay off if you can significantly speed things up. And I am saying this considering that now I run 10 TDL instances side by side (thankfully memory is very cheap these days, and were you to start taking advantage of it, I am sure I will still be able to manage just fine).

Thank you.

[abstr]

>> whether delay-loaded or not

"Delay Loaded' means 'Not Loaded', so switching to a delay-loaded tasklist involves the full load routine.

>> Even when it has 20 task lists open
>> I run 10 TDL instances side by side

Are you saying that you have 10 instances open each containing 20 tasklists?

>> perhaps you can more aggressively cache various things whenever possible

I'll add some logging to 8.0 and if it's still a problem after you've upgraded then we can look at it again.

[abstr]

Can you attach a copy of your preferences please?

[fitnerd]

Thank you for a quick reply, Dan!

Delay Loaded' means 'Not Loaded'

That's what I thought. But on my end in all cases when I pass additional task lists via command line switch -f "PathToTaskList2.tdl|PathToTaskList3.tdl..." with Delayed Loading turned ON, it still makes a huge difference (extra 5-10 seconds per task list) between passing just one (main task list to load) vs passing 5 more task lists using the -f switch. In fact, turning OFF the delayed load option only makes it very slightly slower.

Are you saying that you have 10 instances open each containing 20 tasklists?

I know it sounds a bit crazy, but close to that. TDL is the best tool for hierarchical data with notes and custom attributes (the main use case for me) with the common "currency" - the task - easily copy-pastable between lists of different kinds.

I am just completing reorganization of my TDL setup and will be running 12 instances with each having anywhere from 4 to 15 task lists (not all loaded at once, as by default the delayed load option is turned on, albeit it seems to do little in my case). Eventually - over the course of 1 week on average most task lists will have been loaded on most instances (I restart my computer once every couple of weeks or so). Previously my setup was more like 5 TDL instances and 10-20 task lists per instance.

I only really use Tree view mode and the task lists themselves are not very large - almost all of them are under 1000 tasks and 1MB.

All instances use their own ini file passed via -i switch to avoid conflicts. Most iof the ini files have very similar settings though (just some minor differences like crossing off completed items for example).

I have attached one of the ini files.

Hope it helps.

[fitnerd]

Just did some extra tests with Process Hacker to see the stack traces. And to be perfectly honest I guess this whole slowdown business may be something specific to my machine, even though my original suggestion of favoring more RAM over CPU still stands, as TDL has been so conservative in this regard and thus has plenty of room to utilize RAM better.

My problem is that almost all the time when I looked when TDL was "not responding"/busy I saw traces of "user32.dll!AddClipboardFormatListener" in the call stack, even with both of my clipboard managers not running. This even happens with the TDL instance I built myself when you suggested this a few weeks back. I have not searched the code yet for AddClipboardFormatListener but I remember you saying that you do not use that function. This looks like a mystery I will have to solve myself, as something seems to be hooked up to the TDL process inserting extra calls that cause such slowdowns.

If you have any ideas, I would be grateful. Here's a list of modules loaded by TDL. Perhaps there is something in it that should not be there...

Code: Select all

ToDoList.exe, 0x400000, 2.66 MB, ToDoList
advapi32.dll, 0x768e0000, 480 kB, Advanced Windows 32 Base API
apphelp.dll, 0x73b80000, 628 kB, Application Compatibility Client Library
BCP47Langs.dll, 0x5ea20000, 232 kB, BCP47 Language Classes
BCP47mrm.dll, 0x5ba30000, 116 kB, BCP47 Language Classes for Resource Management
bcrypt.dll, 0x73e40000, 100 kB, Windows Cryptographic Primitives Library
bcryptprimitives.dll, 0x76ec0000, 352 kB, Windows Cryptographic Primitives Library
BurndownExt.dll, 0x2ff0000, 148 kB, BurndownExt DLL
CalendarExt.dll, 0x3070000, 240 kB, CalendarExt DLL
cfgmgr32.dll, 0x75ed0000, 228 kB, Configuration Manager DLL
clbcatq.dll, 0x748e0000, 524 kB, COM+ Configuration Catalog
clr.dll, 0x6bb80000, 7.68 MB, Microsoft .NET Runtime Common Language Runtime - WorkStation
clrjit.dll, 0x6a530000, 548 kB, Microsoft .NET Runtime Just-In-Time Compiler
combase.dll, 0x74500000, 2.36 MB, Microsoft COM for Windows
comctl32.dll, 0x73900000, 2.02 MB, User Experience Controls Library
comctl32.dll.mui, 0xb640000, 12 kB, User Experience Controls Library
coml2.dll, 0x76ba0000, 384 kB, Microsoft COM for Windows
CoreMessaging.dll, 0x5eb20000, 556 kB, Microsoft CoreMessaging Dll
CoreUIComponents.dll, 0x5ebb0000, 2.36 MB, Microsoft Core UI Components Dll
cryptbase.dll, 0x74080000, 40 kB, Base cryptographic API DLL
cversions.2.db, 0x5f80000, 16 kB, 
cversions.2.db, 0x6340000, 16 kB, 
C_1250.NLS, 0x2f90000, 68 kB, 
C_1251.NLS, 0x2f50000, 68 kB, 
C_1252.NLS, 0x2df0000, 68 kB, 
C_1253.NLS, 0x2fd0000, 68 kB, 
C_1254.NLS, 0x2f70000, 68 kB, 
C_1255.NLS, 0x5f50000, 68 kB, 
C_1256.NLS, 0x2e10000, 68 kB, 
d3d11.dll, 0x73180000, 2.32 MB, Direct3D 11 Runtime
DataExchange.dll, 0x733e0000, 316 kB, Data exchange
DayViewUIExtensionBridge.dll, 0x6f70000, 68 kB, 
DayViewUIExtensionBridge.dll, 0x5c190000, 68 kB, 
dcomp.dll, 0x73040000, 1.23 MB, Microsoft DirectComposition Library
dwmapi.dll, 0x73430000, 140 kB, Microsoft Desktop Window Manager API
dxgi.dll, 0x72fa0000, 608 kB, DirectX Graphics Infrastructure
fltLib.dll, 0x77110000, 32 kB, Filter Library
GanttChartExt.dll, 0x91f0000, 344 kB, GanttChartExt DLL
gdi32.dll, 0x743e0000, 136 kB, GDI Client DLL
gdi32full.dll, 0x76d50000, 1.39 MB, GDI Client DLL
globinputhost.dll, 0x5ba10000, 124 kB, Windows Globalization Extension API for Input
iconcache_16.db, 0xbb40000, 1 MB, 
iconcache_16.db, 0xbc50000, 1 MB, 
iconcache_idx.db, 0xb7b0000, 3.55 MB, 
iertutil.dll, 0x725b0000, 2.16 MB, Run time utility for Internet Explorer
imm32.dll, 0x743a0000, 152 kB, Multi-User Windows IMM32 API Client DLL
KanbanBoard.dll, 0x9250000, 396 kB, KanbanBoard DLL
kernel.appcore.dll, 0x741b0000, 60 kB, AppModel API Host
kernel32.dll, 0x764c0000, 896 kB, Windows NT BASE API Client DLL
KernelBase.dll, 0x76f20000, 1.89 MB, Windows NT BASE API Client DLL
KernelBase.dll.mui, 0x2e60000, 952 kB, Windows NT BASE API Client DLL
locale.nls, 0x720000, 788 kB, 
mfc42u.dll, 0x544e0000, 1.17 MB, MFCDLL Shared Library - Retail Version
MFC42u.dll.mui, 0x6f0000, 32 kB, MFCDLL Shared Library - Retail Version
MindMapUIExtensionBridge.dll, 0x6fb0000, 68 kB, 
MindMapUIExtensionBridge.dll, 0x59a00000, 68 kB, 
mscoree.dll, 0x6c480000, 340 kB, Microsoft .NET Runtime Execution Engine
mscoreei.dll, 0x6c3c0000, 564 kB, Microsoft .NET Runtime Execution Engine
mscorlib.ni.dll, 0x6a5c0000, 20.05 MB, Microsoft Common Language Runtime Class Library
msctf.dll, 0x75cc0000, 1.26 MB, MSCTF Server DLL
msftedit.dll, 0x5bcc0000, 2.68 MB, Rich Text Edit Control, v8.5
msimg32.dll, 0x73b10000, 24 kB, GDIEXT Client DLL
msls31.dll, 0x5c000000, 200 kB, Microsoft Line Services library file
msvcp110_win.dll, 0x6fef0000, 412 kB, Microsoft® STL110 C++ Runtime Library
msvcp_win.dll, 0x76860000, 500 kB, Microsoft® C Runtime Library
msvcr100.dll, 0x58bd0000, 764 kB, Microsoft® C Runtime Library
msvcrt.dll, 0x76c00000, 764 kB, Windows NT CRT DLL
msxml3.dll, 0x586f0000, 1.55 MB, MSXML 3.0
msxml3r.dll, 0x25f0000, 4 kB, XML Resources
ntdll.dll, 0x777d0000, 1.56 MB, NT Layer DLL
ntdll.dll, 0x7ffd45d20000, 1.88 MB, NT Layer DLL
ntmarta.dll, 0x6fec0000, 164 kB, Windows NT MARTA provider
ole32.dll, 0x76a80000, 0.98 MB, Microsoft OLE for Windows
oleaut32.dll, 0x74460000, 600 kB, OLEAUT32.DLL
olepro32.dll, 0x58890000, 100 kB, OLEPRO32.DLL
policymanager.dll, 0x6ff60000, 436 kB, Policy Manager DLL
powrprof.dll, 0x74410000, 276 kB, Power Profile Helper DLL
profapi.dll, 0x76960000, 96 kB, User Profile Basic API
propsys.dll, 0x73e60000, 1.5 MB, Microsoft Property System
propsys.dll.mui, 0x6350000, 68 kB, Microsoft Property System
riched20.dll, 0x5c040000, 504 kB, Rich Text Edit Control, v3.1
riched32.dll, 0x58880000, 24 kB, Wrapper Dll for Richedit 1.0
rmclient.dll, 0x72e00000, 132 kB, Resource Manager Client
rpcrt4.dll, 0x740f0000, 768 kB, Remote Procedure Call Runtime
RTFContentCtrl.dll, 0x10000000, 384 kB, RTFContentCtrl DLL
sechost.dll, 0x76470000, 272 kB, Host for SCM/SDDL/LSA Lookup APIs
SHCore.dll, 0x76cc0000, 544 kB, SHCORE
shell32.dll, 0x74970000, 19.29 MB, Windows Shell Common Dll
shlwapi.dll, 0x74350000, 276 kB, Shell Light-weight Utility Library
SortDefault.nls, 0x2930000, 3.21 MB, 
sspicli.dll, 0x74090000, 128 kB, Security Support Provider Interface
StaticCache.dat, 0x94e0000, 18.19 MB, 
TextInputFramework.dll, 0x5ee10000, 500 kB, "TextInputFramework.DYNLINK"
thumbcache.dll, 0x54450000, 296 kB, Microsoft Thumbnail Cache
twinapi.appcore.dll, 0x72e30000, 1.39 MB, twinapi.appcore
ucrtbase.dll, 0x765a0000, 1.11 MB, Microsoft® C Runtime Library
ucrtbase_clr0400.dll, 0x6b9f0000, 684 kB, Microsoft® C Runtime Library
urlmon.dll, 0x727e0000, 1.61 MB, OLE32 Extensions for Win32
user32.dll, 0x741c0000, 1.55 MB, Multi-User Windows USER API Client DLL
user32.dll.mui, 0x58e0000, 20 kB, Multi-User Windows USER API Client DLL
usp10.dll, 0x71c30000, 92 kB, Uniscribe Unicode script processor
uxtheme.dll, 0x73460000, 496 kB, Microsoft UxTheme Library
vcruntime140_clr0400.dll, 0x6baa0000, 80 kB, Microsoft® C Runtime Library
version.dll, 0x73c20000, 32 kB, Version Checking and File Installation Libraries
win32u.dll, 0x740b0000, 92 kB, Win32u
Windows.Globalization.dll, 0x5ba50000, 1.15 MB, Windows Globalization
windows.storage.dll, 0x77120000, 5.73 MB, Microsoft WinRT Storage API
WindowsCodecs.dll, 0x6fd30000, 1.44 MB, Microsoft Windows Codecs Library
wininet.dll, 0x72150000, 4.33 MB, Internet Extensions for Win32
winmm.dll, 0x73d80000, 144 kB, MCI API DLL
winmmbase.dll, 0x73cf0000, 140 kB, Base Multimedia Extension API DLL
winsta.dll, 0x700e0000, 264 kB, Winstation Library
WinTypes.dll, 0x73630000, 856 kB, Windows Base Types DLL
WordCloudUIExtensionBridge.dll, 0x93e0000, 68 kB, 
WordCloudUIExtensionBridge.dll, 0x599e0000, 68 kB, 
wow64.dll, 0x77760000, 328 kB, Win32 Emulation on NT64
wow64cpu.dll, 0x777c0000, 40 kB, AMD64 Wow64 CPU 
wow64win.dll, 0x776e0000, 480 kB, Wow64 Console and Win32 API Logging
wtsapi32.dll, 0x738f0000, 60 kB, Windows Remote Desktop Session Host Server SDK APIs
{6AF0698E-D558-4F6E-9B3C-3716689AF493}.2.ver0x000000000000000a.db, 0x6510000, 288 kB, 
{AFBF9F1A-8EE8-4C77-AF34-C647E37CA0D9}.1.ver0x000000000000006c.db, 0xb5c0000, 196 kB, 
{DDF571F2-BE98-426D-8288-1A9A39C3FDA2}.2.ver0x0000000000000003.db, 0x6560000, 620 kB, 
~DF01071BA3E3A59190.TMP, 0xc7e0000, 512 kB, 
~DF0894361D249E855B.TMP, 0x2c70000, 512 kB, 
~DF1A478C43D2FA8210.TMP, 0xa70000, 512 kB, 
~DF298EA7354F8888C5.TMP, 0x2860000, 512 kB, 
~DF2B11172F11D4F424.TMP, 0x5ed0000, 512 kB, 
~DF3D17C5FD91E4574B.TMP, 0xcd40000, 512 kB, 
~DF4DEF8BC643D97738.TMP, 0xb1e0000, 512 kB, 
~DF5AA20BDCC9353CAF.TMP, 0xaf0000, 512 kB, 
~DF6764C7762EBC48A3.TMP, 0x6b40000, 512 kB, 
~DF79D24EE5ABBCD826.TMP, 0x5e50000, 512 kB, 
~DF7A0A1A78DCCF41AE.TMP, 0x6bc0000, 512 kB, 
~DF984A4B8C42CBD9ED.TMP, 0xcdc0000, 512 kB, 
~DFC55307A78FF8020C.TMP, 0xc1d0000, 512 kB, 
~DFCB15D0EDEA12F129.TMP, 0x6cf0000, 512 kB, 
~DFCCB00547B469E421.TMP, 0x6c70000, 512 kB, 
~DFDD4AC3B42924AE93.TMP, 0xe030000, 512 kB, 
~DFFB777C2512672837.TMP, 0xe0b0000, 512 kB, 
~DFFF714EF0380B50BD.TMP, 0xc250000, 512 kB, 

[fitnerd]

Just checked out latest alpha of version 8 with the usual setup (delay-loading ~10 task lists on startup) and it's the same as in version 7.2: call stacks are plagued by user32.dll!AddClipboardFormatListener (even before main window appears or there is any interaction with UI via keyboard or mouse), which by now I am sure is what causes the lion's share of slowdowns. So, I realize that its highly unlikely to be an issue with TDL then and something to do with my Windows version or setup.

[abstr]

>> I realize that its highly unlikely to be an issue with TDL

But that doesn't mean something can't be done, just as with adding items to the droplists.

ps. This API monitoring tool might be worth a look.

I ran it on 'AddClipboardFormatListener' and it showed nothing, then I ran it on all clipboard functions to be sure I had set it up right and that found correct calls to 'RegisterClipboardFormat'.

apifilter.PNG (9 KiB) Viewed 6774 times

Note: It also displays the module which made each call which might be very helpful to us...

[fitnerd]

Thank you for looking into this Dan!

I did make a few more strange findings...

Whenever I attached the TDL process to VS debugger and randomly paused execution while it was "busy", I never saw any references to "AddClipboardFormatListener" in the call stacks. However, when I would inspect a running "busy" thread in the Process Hacker of the same TDL process, almost all the time I would see "AddClipboardFormatListener" in the call stacks. Now I am starting to think that perhaps Process Hacker incorrectly deduced function names in the call stacks, even though it is using the default "dbghelp.dll" from Windows\System32.

Thank you for suggesting API Monitor. I have got it installed already, but only now remembered that I have it, now that you mentioned it. I will certainly give it a try.

I will also run TDL in a virtual machine on say Windows 7 and Windows 10 to see if it makes any difference.

I also want try to run it from within VS directly from source code to check the loading / switching performance and see if the same issues exist. However I am not sure if using only a specific version of Windows SDK is required to build it, or if any recent SDK version will do.

Thank you for all your help. I will keep you posted on my progress.

[fitnerd]

I have done some tests, and determined the following:

1. For ~10+ task lists, the time it takes for TDL to start and display first (main) task list is the same as it takes for it to finish "loading" all remaining task lists (with delayed loading option) turned on. On a freshly restarted system this amounts to about 6 and 6 seconds respectively, which is not bad.

However, considering the delayed load option is turned on, the "loading" of remaining task lists should be practically instantaneous, and yet it is very far from it - in fact it is possible to see the new tabs appear one by one every 0.5 to 1s.

Clearly this can be improved. On the other hand, some of the delayed-loaded task lists may contain reminders / due dates that should ideally be checked. So perhaps such tasks can be performed in the background (either in a separate thread), or when the program is inactive.


2. I experimented with API Monitor a bit, and it produces a lot of results. However it did not show any clipboard-related calls. I am not completely sure if I were to trust its results considering the program is from 2013 and perhaps does not reflect the later Windows APIs.

However, I was able to see lost (like 100s per second) calls like "GetTopWindow" and "GetWindow" even when the program is completely idle and has no focus (even hidden behind other window) - all seeming related to "WM_IDLEUPDATECMDUI" message.

Code: Select all

#	Time of Day	Thread	Module	API	Return Value	Error	Duration
170596	10:14:28.680 PM	1	MFC42u.DLL	GetTopWindow ( 0x00023dc0 )	NULL		0.0000003
170597	10:14:28.680 PM	1	MFC42u.DLL	GetWindow ( 0x00023dc0, GW_HWNDNEXT )	0x00023e84		0.0000003
170598	10:14:28.680 PM	1	MFC42u.DLL	GetTopWindow ( 0x00023e84 )	NULL		0.0000003
170599	10:14:28.680 PM	1	MFC42u.DLL	GetWindow ( 0x00023e84, GW_HWNDNEXT )	0x00023e82		0.0000003
170600	10:14:28.680 PM	1	MFC42u.DLL	CallWindowProcW ( 0x73921e00, 0x00023e82, WM_IDLEUPDATECMDUI, 1, 0 )	0		0.0000014
170601	10:14:28.680 PM	1	COMCTL32.dll	GetWindowLongW ( 0x00023e82, DWL_MSGRESULT )	330911168		0.0000003
170602	10:14:28.680 PM	1	COMCTL32.dll	DefWindowProcW ( 0x00023e82, WM_IDLEUPDATECMDUI, 1, 0 )	0		0.0000000

I am not sure of the actual performance impact of this because it was hard to measure, but in any case this behavior seems excessive. Why do all of this even when app does not have focus, and why do it so often?


3. The general slowness which affects everything, but in particular starting TDL (while (delay)loading a bunch of task lists) or task list switching seems to be related in my case to how long the Windows OS was running (either hibernation count, or in general number of hours). So, I guess it is not really a TDL issue directly, however I have noticed its effects primarily on TDL, as pretty much all other programs seem far more responsive and do not degrade in performance anywhere near to how much TDL does.

For example browsers, Office apps, Thunderbird email client do not seem to degrade in performance at all. Explorer, and some win32 apps that rely heavily on user32 and gdi32 do slow down about 50% after 10 days. But TDL, as my measurements have shown slows down by almost 10 times in 2 weeks:

Win7 VM x64 Fresh: 4-5 seconds to first loaded task list, 10-11 seconds to fully loaded (delayed-loaded rest of task lists)

Win8.1 VM x64 Fresh: 5-6 seconds to first loaded, 11-13 seconds to fully loaded (delayed); switch to not-yet-loaded task list -7 seconds

Win10 1803 x64 Real System after running for 10 days: 40 seconds to main window being shown, 1 minute until first task list is loaded, 3-4 minutes till all 10 task lists are delay-loaded

Win10 1803 x64 Real System after most apps closed, running for 10 days: 10 seconds to main window, 20 seconds to first loaded task list, 1-2 minutes till all 10 task lists are loaded; switch to delay-loaded task list - 14 seconds

Win10 1803 x64 Real System after restart: 4-5 seconds to main window, 6-7 seconds to first loaded task list, 20 seconds till all 10 task lists are delay-loaded; switch to delay-loaded task list - 10 seconds

The numbers above are cumulative (i.e. the total time - when all task lists have been delay-loaded and window disaplyed is the last time, aside from task list switching which is separate)

Oh, and even in the cases where system was running for 10+ days and apps have not been closed, neither the CPU nor RAM are the issue - system has at least 10GB of free RAM, and CPU is used only up to 25%, it being a 6-core CPU this is hardly a problem, especially for mainly single-threaded TDL.

I guess is that TDL heavily relies on user32-related resources, which are slowly being used up as the system stays on, leading to considerable performance degradation over time, until a full system restart is performed.


Hope it helps.
If you have any suggestions on the user / gdi resource depletion front which is likely the cause of many performance issues with TDL on my end, that would be great!

[abstr]

>> all seeming related to "WM_IDLEUPDATECMDUI" message.

This is the MFC framework's implementation of 'idle processing' which occurs when there are no other Windows messages to process. It allows toolbar buttons and status bar panes to 'update themselves' without the programmer having to update them after internal state changes. The problem is that the updating goes on even if the app is not active, although not if the toolbars or status bars are explicitly hidden (View > Bar Visibility), so you should find that this processing falls to 'zero' if you hide all the toolbars and status bars.

I've added a task to 8.0 to take a closer look.

>> If you have any suggestions on the user / gdi resource depletion

This possibility has also occurred to me. NirSoft's GDIView looks like a good starting point for establishing what handles might be leaking by taking periodic snapshots. Not sure if it can be configured to automatically take and save snapshots, but this might be a task for AutoHotKey. After that API Monitor can be use to log all the relevant system calls and/or there's this article on tracking down orphan GDI resource creation.

If you can perform the first step and attach whatever results you can extract, then it might help narrow down my search for errant code. I've added a task to 8.0 to take a closer look.

>> Win10 1803 x64 Real System after running for 10 days: 40 seconds to main window being shown, 1 minute until first task list is loaded, 3-4 minutes till all 10 task lists are delay-loaded

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

If so, can I suggest turning on ToDoList's own logging (add '-g' to the command line) since this logs startup performance quite extensively, and might tell us if the slowdown is spread evenly across the startup functions or not...

It might also be helpful, after enabling logging, to reboot your computer (when it suits you of course) and performing 4-5 startups in quick succession, renaming the log file each time (to be able to later compare them), so that we can confirm whether TDL's performance is consistent (or not) and to hopefully establish a reliable baseline startup time for our investigations.

Then at fairly even intervals of a couple of days you could restart TDL and compare the log file with the baseline to see if there is any sort of (linear) relationship between TDL's startup time and the time since your computer's last reboot.