The database uses SHM (shared memory) segments. Not sure if kactivitymanager can use these with FreeBSD.

FreeBSD does have Posix SHM. 
Looking at how it has been working just great for a long time and only recently started slowing down so even if it's done differently how come it worked flawlessly for years?

I don't know how kactivitymanagerd is supposed to work/use the three files on a daily basis. For example, is it taking content from database and moving/copying it? I see that database is usually a couple of days behind database-shm and database-wal. The latter two are usually within the same day.

database varies in size typically a few hundred K to a few M.
database-shm is always 32768. Content is usually mostly zeros. On the set of files that really slowed down Plasma -shm had 77 bits. On my current with much less visible slows we have 1f8 bits (at the beginning of the file).
database-wal varies but have about 2.7Mb of data.

As you can tell I'm fumbling in the dark as I don't know how to really trace down what is going on or what to look for. Though what seems obvious is that -wal is a sqlite db, the -shm is a copy of what should be in SHM and database is a clear text where the content is copied not moved from.

When I use a LOT of nodes in Inkscape, that is where I typically notice a slow. Recently I had a pretty simple image and I would sit around waiting for quite a while after making a change. Then I noticed that if I went to a different window and clicked it seem to snap out of it and catch up with updating the screen. 

As a side note, I've not seen any odd behavior otherwise. I've used KDE since the early days and never found anything that I liked better so I'm quite familiar with it. An annoyance is that it does not remember that I'm using virtual channel 4 on the sound card and have to tell it each time I boot.

I'm not a C developer so I can't trace it myself.

Hi Steve,

Those files are automatically handled by sqlite. WAL is a write-ahead-log - a technique sqlite uses to avoid updating the database for each sql insert/update command. It writes the updates to WAL and then merges a chunk of them at once. KAMD only tells sqlite to flush WAL every 400k instead of the default 4M. Now, sqlite is free to ignore this request - it flushes only if the flush can be fast enough. So, the WAL file can grow more than that.

This code (in KAMD) hasn't really been changed in 5 years. Did freebsd get a new version of sqlite recently?

Now, Inkscape and KAMD have nothing in common - if KAMD manages to slow down Inkscape, my guess is that the OS doesn't handle file writes as it should. Maybe Inkscape is also trying to write something to the hard drive. Can you watch whe process IO with iotop to see what KAMD and Inkscape do when you experience the slowdown. Also, can you track the RAM usage while this happens?

My FreeBDS version was 12.1 which had the same sqlite since Jan 2019 FreeBSD-EN-19:03.sqlite. So it was not really a new one. I've since upgraded to 12.2 and it has V20:22.sqlite. The situation have not changed.

There is no requirement to run Inkscape to get a lag. The slowdown is the whole UI, nothing will respond during the lag. Though it does sometime cache the requests and execute when it returns.

I have ten desktops, each with some specific purpose such as dedicated to email. In addition there are three monitors, one is 4K and two are 1080p. I don't have three because it looks cool but because I do a lot of things and three monitors are in constant use for video editing, programming and configuring apps and servers. There could easily be 30+ windows and tabs, some windows may have been open for a long time (weeks).

I often have a lot of activities which I cycle through, for example, 4 browser tabs for remote managing of Open edX, another 6 researching something, another bunch for handling something else and then maybe Inkscape, GIMP, online shopping. 

Simply killing off tabs and browsers have not solved it. The database simply keeps growing. Once the lag becomes noticeable there's no way out other than deleting one or more of the database* under kactivitymanagerd. I will be able to do some UI and then I'm waiting for seconds to pass which could be 10 before it returns control.

Other observations are kwin_x11 running pretty flat out (70-100%) on a core (probably normal?). There's no swap used. :) Usually 100G+ free RAM.

As a workaround I have a saved set of database files which I copy over the active ones, which usually noticeable when I have over a MB in one or more of the database files (database/database-wal), though it I see the UI lag with only -wal being that large. 

I'm not claiming to having properly identified where the lag is coming from, simply sharing observations and some simple tests as I stumble around. Also, I do think it's possible that I may have some extreme use case

This comment also updates my versions up to:
KDE Plasma Version: 5.20.4
KDE Frameworks Version: 5.77.0
Qt Version: 5.15.2
V20:22.sqlite

Thanks for the bug report, and I'm sorry we weren't able to figure it out yet. A lot has changed since this was reported; can you still reproduce the issue in Plasma 6.3.5 or later? Or even better, in the Plasma 6.4 beta or the 6.4 final release in a few weeks?

Thanks again!

🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME.

For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging.

Thank you for helping us make KDE software even better for everyone!

🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME.