Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Atrocious performances since v3.0 #2020

Open
LeCalicot opened this issue Dec 28, 2023 · 3 comments
Open

Atrocious performances since v3.0 #2020

LeCalicot opened this issue Dec 28, 2023 · 3 comments
Assignees

Comments

@LeCalicot
Copy link

LeCalicot commented Dec 28, 2023

I haven't used Tagspaces since the v2.9 (yeah, that's a long time ago). I wanted to use it again but the performances are much worse than back in the days and make it unusable

Describe the bug
With:

  • 350 tags
  • 800 files in the folders
  • about 4 tags per file
    any version >3.0 becomes very very slow:
  • about 10 second to preview an audio file
  • about 20s to load the file list
  • all the actions take a long time (adding tag, delete group,...)
    ...with my newer computer (AMD Ryzen 5 3600). With my old laptop from 2016 it is unable to load at all.
    I have tried to copy the files on a SSD but the performances are similar.

Expected behavior
With the version 2.9 (and earlier), I can open the same folder as above with my potato laptop easily.

Desktop Application:

  • Operating System: ubuntu 18.04, windows10
  • TagSpaces Version 5.5.4 vs 2.9
    tested for both OS.

Additional problems
Incidentally, the release v2.9 for linux does not work on ubuntu 22.04. Any idea for a workaround?

I guess there won't be any fix because it would require deep architecture changes, so it's more to let you know that for my application, tagging a moderately large music database, Tagspaces has become unusable.

In the end, I might write my own software to parse my existing tags in another programming language...
Or is there anyone who tried that already?

@LeCalicot
Copy link
Author

Just to give more information about why tagspaces was a good fit for my use case:
The color tag system allow to explore large list of files and pinpoint information by the color very quickly. I have tagged all my music for creating music playlist live. Having everything in a single list allows to create a visual memory of the files in the folder.

Therefore, pagination is not a fix because I need to explore the files quickly and the page number will change with new files added to the folder. The performances are so bad with that many tags that it does not improve sufficiently anyway.

For the same reason, subfolders are not an option, I need to parse visually as much information as possible at the same time.

Similarly, using the search function with subfolder or pagination remove the serendipity side of tagspaces, I would not be able to find files I was not exactly looking for. Moreover, it forces to use the keyboard to find what I want.

@sytolk
Copy link
Member

sytolk commented Dec 30, 2023

Hi, tagspaces is tested with 1000 files with tags https://github.com/tagspaces/tagspaces/blob/develop/tests/create-1000files-nothumbs.sh and there is no performance issues. If you can create github testing repository with your 800 files that can repeat this issue I can take a look. Maybe you issue is connected with a file type: audio ?

@LeCalicot
Copy link
Author

LeCalicot commented Dec 31, 2023

I have done a few tests on my computer.

Setting up the files

Here is a small python script that I have used to create a lot of files:

from pathlib import Path
import random
import string
import shutil

# An empty folder where to copy the files
TEST_FOLDER = Path("#REPLACEME")
# An original file to copy
DUMMY_FILE = Path("#REPLACEME")


def rand_name():
    return ''.join([random.choice(string.ascii_letters) for _ in range(20)])


def copy_file(copy_nb: int, extension: str):
    for _ in range(copy_nb):

        name = rand_name() + " [" +' '.join([''.join([random.choice(string.ascii_letters) for _ in range(4)]) for _ in range(5)]) + "]" + extension
        print(name)
        shutil.copyfile(str(DUMMY_FILE), TEST_FOLDER / name )
    

if __name__== "__main__":
    # just indicate the extension of the file you copied and how many time you want to copy it:
    copy_file(1000, ".ogg")

just replace the #REPLACEME with the correct paths.

Test conditions

The condition I have used to test are:

  • Tested with Ubuntu 18.04 on my 2017 laptop (I could not install v2.9 on ubuntu 22.04, segmentation fault).
  • 1000 files
  • 5 tags each of 4 letters (none of them are known)
  • totally empty tag database
  • Just open tagspaces and open the location
  • Display files as a list of 1000 files (no pagination!!)
  • Interact with the file (select, add/remove tags, play preview)

I have used a .ogg file (here renamed in .mp4) with silence in it:
https://github.com/tagspaces/tagspaces/assets/3332394/bcde4e9e-69ba-4496-9dc1-b8c29ea38165

Results

Then I have tested with 2 different versions of tagspaces:

  • With the v5.5.4: every interaction takes about 4s or more (seleecting, starting preview,...)
  • With the v2.9: every interaction is about or below 1s, which is acceptable

I have tested with .jpeg files using the same script, the performance are about the same, the loading is a bit worse due to the thumbnails.

With files without tags, the v5.5 is more reactive

Similar performances are found for the v5.5.4 on ubuntu 22.04 on my newer computer, similar performances for the v2.9 are found on windows 10 on my newer computer (dual-boot).

With pagination, it works relatively fine, but that's a setting I do not want to use.

Conclusions

  • Tagspaces becomes very sluggish with the number of files increasing
  • the number of tags in the library does not matter
  • whether the tags are known or not does not matter
  • the type of file does not matter (except for thumbnail generation, but that's not the issue here)

@sytolk sytolk self-assigned this Jan 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants