Hey Andreas, do you think it is worth implementing "Number of entries to keep" like there's "Keep items in history for x days" - one or the another?
I know you are busy with various other things, but do you still plan to implement fuzzy, regex and other type of searches?
is the number of entries really something that would be of interest to you? I could easily add this, but there are already so many options, not sure whether this adds anything useful
For the searches, yes that's on my TODO list. Need to figure out how to do that in a performant way with Apple's Core Data
Use-case for the "Number of entries" - let say I'm on a long leave and upon returning most of my clipboard entries are gone or even the all of them. I could easily set this to 100days, but this will create a huge DB, which I guess will cause the CM to perform worse. At the moment I'm keeping entries for 16 days which are 2471 entries (at the moment) == 37MB.
BTW, I've just deleted ~ the half of my entries, but the DB size is still 37MB is this expected?
I'm trying to figure out why the CM is acting slow - I mainly notice this when opening and closing it + it take some time to load the content inside the right panel:
I thought that it could be due to the DB size/number of entries, but even with less than 800 entries it is behaving the same way. Maybe because still the DB size is 37MB?.
The size of the database should not make a difference for the speed (mine is currently at about 1GB).
Does it always take so long to show for you? (It should only do that on the first load)
@xidiot would be great if you could check whether 5.370 helps with the performance issue in your video
Does it always take so long to show for you? (It should only do that on the first load)
Yes, something might have changed in the previous versions (or something on my end could have changed?), since it was not an issue sometime ago.
@xidiot would be great if you could check whether 5.370 helps with the performance issue in your video
At first I thought it might fixed the right pane slowness, but then I've noticed that the middle/main pane sometimes took a bit longer to load check the video - the right pane is showing the text but the middle is not fully loaded:
And at the end I sometimes end up with both panes empty for half a second (or less):
Could you check with 5.373? It feels pretty instant here with that. For me it was fast with the previous version as well, however I mostly tested on my M4 Max, so now I did some fine tuning on my M1 machine, maybe that helps.
Thanks you, I think it is helping with the empty panes, but it is still not really responsive for show/hide (especially for hide) of the whole CM.
Additional info - I've just noticed that upon showing the CM the BTT's CPU usage spikes from ~2% to 20% (in Activity Monitor), but then I've decided to check using old school ps and here's the result:
2025-05-09 14:07:36 - 93933 CPU Usage: 0.4%
2025-05-09 14:07:37 - 93933 CPU Usage: 0.1%
2025-05-09 14:07:38 - 93933 CPU Usage: 0.1%
2025-05-09 14:07:39 - 93933 CPU Usage: 1.0%
2025-05-09 14:07:41 - 93933 CPU Usage: 1.4%
2025-05-09 14:07:42 - 93933 CPU Usage: 2.9%
2025-05-09 14:07:43 - 93933 CPU Usage: 1.0%
2025-05-09 14:07:44 - 93933 CPU Usage: 0.4%
2025-05-09 14:07:46 - 93933 CPU Usage: 8.4%
2025-05-09 14:07:47 - 93933 CPU Usage: 9.7%
2025-05-09 14:07:48 - 93933 CPU Usage: 0.3%
2025-05-09 14:07:49 - 93933 CPU Usage: 0.4%
2025-05-09 14:07:50 - 93933 CPU Usage: 2.2%
2025-05-09 14:07:52 - 93933 CPU Usage: 0.3%
2025-05-09 14:07:53 - 93933 CPU Usage: 0.5%
2025-05-09 14:07:54 - 93933 CPU Usage: 0.4%
2025-05-09 14:07:55 - 93933 CPU Usage: 1.8%
2025-05-09 14:07:57 - 93933 CPU Usage: 11.7%
2025-05-09 14:07:58 - 93933 CPU Usage: 83.3%
2025-05-09 14:07:59 - 93933 CPU Usage: 6.3%
2025-05-09 14:08:00 - 93933 CPU Usage: 0.3%
2025-05-09 14:08:01 - 93933 CPU Usage: 0.3%
2025-05-09 14:08:03 - 93933 CPU Usage: 5.8%
2025-05-09 14:08:04 - 93933 CPU Usage: 0.1%
2025-05-09 14:08:05 - 93933 CPU Usage: 0.1%
2025-05-09 14:08:06 - 93933 CPU Usage: 0.1%
2025-05-09 14:08:07 - 93933 CPU Usage: 0.4%
2025-05-09 14:08:09 - 93933 CPU Usage: 0.1%
2025-05-09 14:08:10 - 93933 CPU Usage: 1.5%
2025-05-09 14:08:11 - 93933 CPU Usage: 29.4%
2025-05-09 14:08:12 - 93933 CPU Usage: 0.2%
2025-05-09 14:08:13 - 93933 CPU Usage: 0.1%
2025-05-09 14:08:15 - 93933 CPU Usage: 1.1%
11.7% and 83.3% are when I've opened it and the 29.4% is when I've closed it - both actions done via shortcut.
I can provide more details (or more examples like the above one) if needed.
Apple M1 Pro
macOS: 15.4.1 (24E263)
Memory 32GB
That CPU usage seems fine.
Hide is slow for you as well? That's even more weird 
That should always be absolutely instant, especially since I disabled all animations a while ago.
Just to be sure, how are you hiding the Clipboard Manager?
This is how it should behave like:
Both showing and hiding are done via shortcut:
Yeah, when you disabled the animations the improvement was great indeed:
In the below video I'm showing/hiding BTT's CM and Maccy with the same frequency - the only time I stopped pressing the shortcut for BTT's CM was around the 18th second
I'm currently a bit out of ideas of what could make it slow. Could you post a screenshot of the settings?
In 5.374 (uploading) I'm debouncing some rendering calls, would be great if you could checkout that version as well and see whether it makes a difference
Still the same :\
Strange, I'm currently out of ideas. I tried on my old Intel machine, but even there it is loading fast (it feels like it appears instantly when hitting my keyboard shortcut).
Maybe something got corrupted somehow at the database level. Maybe you could try to temporarily move the database files to some other location (while BTT is quit) and see how it behaves with a fresh database.
~/Library/Application Support/BetterTouchTool/BTTClipboardManager_20241210.sqlite
~/Library/Application Support/BetterTouchTool/BTTClipboardManager_20241210.sqlite-shm
~/Library/Application Support/BetterTouchTool/BTTClipboardManager_20241210.sqlite-wal
On an empty DB, show/hide is instant. With around 10-20 entries still feels instant, I'll need to ...copy more items and report back. Thank you.
BTW, what do you think about the use-case I've shared yesterday:
Use-case for the "Number of entries" - let say I'm on a long leave and upon returning most of my clipboard entries are gone or even the all of them. I could easily set this to 100days, but this will create a huge DB, which I guess will cause the CM to perform worse. At the moment I'm keeping entries for 16 days which are 2471 entries (at the moment) == 37MB.
The database size really shouldn't make a difference because BTT doesn't load the item content into memory when not needed. My database has regularly been over 1GB. If bigger sized databases cause issues, then I need to address these instead of only supporting small databases.
I think the problem might be something else (database related), but I'm not yet sure what.
Hey Andreas, I now understand that the DB size should not matter, but the main part/concern of my use-case is:
let say I'm on a long leave and upon returning most of my clipboard entries are gone or even the all of them.
Like mentioned - I can set to 100 days (or more) of history, but this will make the CM filled with so much entries and it will be hard to navigate/search thru them + it will take unnecessary space.
I've just updated to Version: 5.376 (2025050906) and something else started happening - you can see at 3rd-4th sec and 11th-12th sec that the CM is not closed, but the content of in the right pane is disappearing. This happens upon triggering the shortcut for show/hide.
I think ChatGPT just helped me figure out a potential performance issue and also came up with a better high performance solution. This will also allow for more dynamic search.
It will require a bit of refactoring, I'll try to adapt this as soon as possible.
For now I have added a hidden max item setting in 5.377 (run while BTT is quit):
defaults write com.hegenberg.BetterTouchTool BTTNumberOfItemsToKeepInHistory 1000
Note: items are only deleted on BTT startup (regardless of days or number setting)
Btw, I think I've figured out that a particular app contributed to the slowness of CM - MultiTimer. It seem that when left running for a long period and there is/are timer(s) in COMPLETED status (even in this status the timer continue to measure time, but starting from the time when it reached COMPLETED status - so not a bug, but a useful feature):
the whole macOS starts acting slow - but BTT's CM was the one I've noticed since I'm using it quite often + the delay was really noticeable.
Once MultiTimer is closed/restarted macOS starts working normally and the CM started to act better + the new DB definitely also helped.
Note: items are only deleted on BTT startup (regardless of days or number setting)
this makes sense, but I guess most of the users have enabled BTT in the macOS' login items.
