I’m running 5.0.5 on Linux, I’m now up to ~400 tags defined in ~10 tag groups, applied to several thousand files using file names not sidecars.
I’ve witnessed a steady increase in UI lag. Even with only 20 items visible, I can only get the delay when tagging a file down to ~3 seconds rather than 5-10 seconds when more items are visible. Tagging a group of 20+ files takes enough time for one to take a coffee break, forcing me now to only use TagSpaces to audit / QC tags I apply to file names externally. It’s visualization capabilities are super valuable still to proof the tags, even if it takes 20 second to load 60 items into the grid view
But… taking so long to rename a few files and refresh the LevelDB makes the functional yet inefficient code start to feel like a bug…
As a benchmark: Krename on my system can rename ~3,000 files in a bit more than a second. (I know because I now use it a lot as a workaround.) And opening a folder of 1,000 images (after wiping the system’s thumbnail cache) takes just a few seconds to generate thumbnails and is non-blocking to the UI. But of course these’ aren’t operating in an Electron container… I don’t have much experience with Electron or LevelDB, so don’t know what to expect or what is possible. My laptop is only a year old, high spec, and i use it to edit video, play 3d games on steam, etc… Everything I do in Linux is blazing fast, except, sadly, TagSpaces…
On to my question:
Is this drop in performance…
a) A known issue, already understood to be limited to the Electron implementation for MacOS & Linux. (Meaning windows and mobile versions of the app are highly performant with large datasets.)
or is it b) generally accepted that when handling a lot of tags and files, TagSpaces will bog down. (Meaning it wasn’t designed or intended for large datasets.)
I really like TagSpaces and am genuinely interested in helping make it better because it has a lot of promise in my opinion. It’s been a bit of a struggle though, I won’t lie. Thanks for your time!
Some users are reporting performing issues when they have a large tag library like containing over 500 tags. We are planing to optimize this by extracting the tag library from the core of the application in version 5.1 or 5.2 …
In case it helps anyone, my intensive use of the app in the last week or two has yielded some insights. The slow UI updates let one see step by step how it’s being so inefficient. Good news is that I strongly suspect there are some low hanging fruit basic optimizations that could dramatically improve the product.
The amount of time it takes to update a single file’s tags seems proportional to the number of files in a folder. This points a smoking gun at a certain business logic area of the code. It seems to be repeatedly doing something that is dependant upon a full rescan of all fles and/or the database, rather than just revising the one record in question. Perhaps it’s even doing background tasks like updating the search index - in the foreground in a modal manner.
What happens: If you change a tag on one file, with 3 items in the folder, it’s quite useable. But do it in a folder with 75 files each with ~10 tags, and we’re punished with 20-30 seconds of waiting. Efficient code would be time invariant in this respect.
Selecting multiple files and then applying a tag to the whole selected group can be brutal bad. It’s clearly doing each update one by one, causing the delays from point 1 above to snowball / accumulate. If you have a large folder and try to apply tags to a lot of files, the whole app can be frozen in deep concentration for minutes to hours.
It of should be batching operations efficiently to avoid needless loops, resulting in roughly the same required time to tag one as for tagging 100 files.
The inefficiencies of having lots of tags and tag groups in the left Tag organizing area are real, there are clearly optimizations to be had. Managing a list of 400 values applied to a few thousand DB records, and maintaining a search index just is not a hard task these days for the kinds of powerful computers we all enjoy. But every small inefficiency in this process is being exacerbated by points 1 and 2 above.
The app struggles with thumbnail gallery presentation when any significant number of tags are involved in the files themselves. Just clicking a folder with page size 100 files that have 5-10 tags each can be brutally slow taking up to a blocking minute and chew on. Reducing the number of visible items on each page helps, so it seems tied to some inefficiencies in how a file’s thumbnail and tags are being loaded, and a lack of asynchronous activity. The UI shouldn’t block while mundane stuff like search index updating and thumbnail proofing are occurring.
Have you tried to reduce the number of files on one page? There is a setting in perspective where you can choose different values for this. Having some tags on every file is still an edge case for me. In this case maybe a database backed solution will suit better for your use cases. In regards of tagging we try to keep TagSpaces as simple as possible, in order make the tags portable and not vendor locked in some service.
But nevertheless, there is for sure optimization potential in the app on many places…
Hi
we have the same performance-issue, the cutomer that i support has boughtTagSpaces Pro but loads of files and uses the tags intensively.
We can offer to help testing.
Yes. the performance is a bit better if I reduce the number of visible items per page in the settings. But even 20 is too many if the files have a lot of tags. It’s horrible… At the moment i have to tag photos in a temporary folder in batches of 5 to 10 photos. Any more and I just spend the entire day watching Tagspaces perform incredibly inefficient sequences of file operations…
Please try it out. Get a thousand files in 100 folders and 300 tags in 8 tag groups. Then put a random mix of 5 to 15 tags into the file names. “Description[tag tag tag tag etc…].ext” In my case TagSpaces becomes nearly unusable.
I now only edit file names manually using external file name tools, and then only open them in Tagspaces to QC my work, as the colored tag groups help me see if I forgot a category section which I consider “required”, while also highlighting Spelling or Capitalization errors. I can’t even browse the photos in TagSpaces any more, it’s too slow.
But even this crude visualization assistance is still valuable to producing accurate tags, because then my normal Linux file search is totally TURBO CHARGED! Just using my normal file explorer, it’s delightful to take advantage of the search term tags that are now in the file names. We’ll be in heaven if your team can crack these efficiency issues! Please make TagSpaces as pleasant and snappy to use for organizing files as the standard File Explorers that our OS’s provide! Then we’ll just stay in TagSpaces all day long…
I just saw an update notification and downloaded and installed 5.1.1. Could it be that the version number in the app still says 5.0.5? The old .deb says a newer version is installed, i just don’t have a solid way to confirm that 5.1.1 is really running.
Despite the old version number reported, since I’ve installed the update, performance has improved considerably. Not sure what changed but it no longer takes 15 seconds to open a folder with 20 items, it’s now only 2-3 seconds which is very nice. Dragging a tag onto a file actually works in a reasonable time.
I will test more to see if this speed boost degrades through continued usage like the old version did.
– Update
Ends up I’ve unwittingly been using the AppImage all this time. That’s why installing the new DEB didn’t result in a new version number. Duh. It’s now cleaned up, app image removed. I’m using the DEB installer, 5.1.1 and version number is correct. Performance is still better for some reason than it was before updates. Will keep testing - thanks!!
Chiming in just to put some emphasis on the performance issues.
I love tagspace, I am using it for over a year, but the one thing that would really make a huge difference for me is improving the performance in big folders.
Examples: Just a single-click on a folder, and I have to wait about 700 ms to see the folder selected. Double-clicking a folder is around 2-3 seconds to see it’s content. The folder I am clicking only contains 3 files and it is already processed. So it’s just navigating between already processed folders.
If my root folder is smaller, the navigation is faster both ways. But if my root folder is huge, even going to a small folder takes as much time as hitting the back button.
The other thing is the click and drag of tags to tag another file. I find that very useful, but in big folders there is a 1s delay after each click, like it really needs to process something before the drag functionality is activated each time. Maybe it’s trying to do dynamically too many times something that could be cached or kept in memory?
P.S. I am on Windows and my computer is quite new, 8-core CPU. Navigating with explorer feels like 1ms in those folders, so hardware is not the issue.
The poor performance is the main turn-over for me. I have a folder with around 3000 photos in it - and it barely usable - and only when I choose “100 per page” view option - anything higher than this and TagSpaces hangs and became not usable - the restart of the app is required. I’m on TagSpaces 5.2. Tagging and viewing is the CORE feature of the app, and I can’t use it because of the performance issues. Using 100 per page option is also quite slow with a lot of tags, and I often need to view more at once because this folder contains a lot of similar photos (which is easier to visually analyze with higher images per page option). I’ve tried to use TagSpaces 4.x and dropped using it because of the same issue.
As an illustration: this folder contains JPG files, converted from RAW files. Which means that JPGs are usually easier to process in terms of the performance. And for RAW files I found “FastRawViewer” app - which is blazingly fast viewing the same photos in RAW format. The folder with RAW files opens instantaneously, image previews open so fast that I didn’t notice the delay. But “FastRawViewer” can’t add/manage tags. Both JPG and RAW folders are on an SSD.
Why this issue isn’t the highest priority and not in the roadmap?
Just using my normal file explorer, it’s delightful to take advantage of the search term tags that are now in the file names. 
We’ll be in heaven if your team can crack these efficiency issues! 
Please make TagSpaces as pleasant and snappy to use for organizing files as the standard File Explorers that our OS’s provide! Then we’ll just stay in TagSpaces all day long…