What’s especially strange to me is that there’s seemingly not much high-level code distance between Uploaded and Completed messages:
A more normal look (except for speed on this debug build, which seems oddly low and unpredictable) is:
2024-04-25 15:45:18 -04 - [Profiling-Duplicati.Library.Main.Operation.Backup.BackendUploader-UploadSpeed]: Uploaded 48.34 MB in 00:01:04.3566658, 769.22 KB/s
2024-04-25 15:45:18 -04 - [Information-Duplicati.Library.Main.BasicResults-BackendEvent]: Backend event: Put - Completed: duplicati-b5e32ab48f30e4e4da36d66fa08f8d902.dblock.zip.aes (48.34 MB)
I suppose you could look at your logs to see if your Completed is typically a quick follow to UploadSpeed.
CUSTOMSQLITEOPTIONS_DUPLICATI is its name. Was EXPERIMENTAL_CUSTOMSQLITEOPTIONS_DUPLICATI and you can probably find several usages under one or the other in the forum and possibly GitHub Issues.
set CUSTOMSQLITEOPTIONS_DUPLICATI=cache_size=-200000 is how a batch file gets 200 MB of cache.
Command Prompt and manual launch can also be done. Changing environment variables for a Windows service is awkward compared with a Linux service where it’s very easy. Windows might need a global set.
The optimize/analyze are probably something the code would have to do, so that’s a developer suggestion. You might have read of PRAGMA optimize at database close, but for initial backup, that’s a long time away. Database proper close also doesn’t happen if process is killed, so next try still hasn’t had analyze benefits.
This is asking too much for most people, but if something like DB Browser for SQLite is used, you can do PRAGMA analyze there (assuming database will open) if you have to do a process kill (so miss optimize).