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

Huge performance difference with two nearly identical SGF files #125

Closed
FelixBrendel opened this issue Sep 6, 2016 · 2 comments
Closed
Milestone

Comments

@FelixBrendel
Copy link

Sabaki seems to perform a lot worse, when the SGF file contains many separate games in contrast to the same amount of variations of an empty board. Here is a zip containing two nearly identical "large" files. After opening large1.sgf, placing stones doesn't have any delay, with large2.sgf placing stones has a 1 second delay (at least on my machine).

I don't know if this is a bug or maybe can be designed better (or maybe the design doesn't allow this).

@yishn
Copy link
Member

yishn commented Sep 7, 2016

Interesting... Running a CPU profile yields that the perpetrator is Sprint, a jQuery-like DOM manipulator. I think this is because of the sheer amount of HTML elements that are generated for each game inside the SGF collection.

@yishn yishn closed this as completed in e65c218 Sep 7, 2016
@yishn
Copy link
Member

yishn commented Sep 7, 2016

This fixes the delay when placing stones. I'm keeping this issue open for the delay when opening the 'Manage Games...' dialog. Maybe we can try generating the SVG preview images on the fly (while scrolling)?

@yishn yishn reopened this Sep 7, 2016
@yishn yishn added this to the v0.18.0 milestone Sep 7, 2016
@yishn yishn mentioned this issue Sep 7, 2016
@yishn yishn closed this as completed in #126 Sep 8, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

2 participants