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

Low performance rendering big Tree objects #551

Closed
SergioLuis opened this issue Sep 25, 2021 · 4 comments · Fixed by #552
Closed

Low performance rendering big Tree objects #551

SergioLuis opened this issue Sep 25, 2021 · 4 comments · Fixed by #552
Labels
bug Something isn't working

Comments

@SergioLuis
Copy link

Information

  • OS: macOS
  • Version: Big Sur 11.5.2
  • Terminal: iTerm

Describe the bug
Rendering big trees is noticeable slow in spectre.console - moreover compared with other tools in which the same rendering seems to happen instantaneously.

To Reproduce
I'm playing with the library by creating a clone of the tree utility. For this, first i traverse the FileSystem, then build the Tree object, then render it using AnsiConsole.Render. This is the detailed log of how much time each operation took:

23:23:49.537 FsTree - Started walking tree '/Users/sluisp/wkspaces/codice'
23:23:50.281 FsTree - Finished walking tree. Found 10703 directories and 95 files
23:23:50.287 FsTreeCommand - Started rendering the tree with AnsiConsole
23:23:50.290 RenderTree - Started building Spectre.Console.Tree object
23:23:50.369 RenderTree - Finished building Spetre.Console.Tree object
23:24:35.030 FsTreeCommand - Finished rendering tree
  • Traversing the FS: 744ms
  • Building the Spectre.Console.Tree object: 79ms
  • Calling AnsiConsole.Render with that tree: 84661ms

As you can see in the logs, the tree is comprised of 10798 nodes. It's quite big, but for a FileSystem I would consider it quite standard. Each node is only plain text - no text colors, no tables, not anything fancy. A exact tree clone regarding what goes to the screen.

Expected behavior
The rendering could be faster. I'm sure lot's of things are happening behind the scenes, but... maybe there is room for improvement :)

Or maybe I'm using the library wrong and I need to adjust a buffer or something like that for it to work faster, but I didn't found anything documented.

@SergioLuis SergioLuis added the bug Something isn't working label Sep 25, 2021
@phil-scott-78
Copy link
Contributor

You have a reproduction I could pull down? I'd like to take a look at it in dottrace and see what we can do to speed it up

@SergioLuis
Copy link
Author

Sure! In the attached ZIP file you can find the directory structure I tested this with.
fstree-perf-test.zip

And in the following GitHub Gist you can find a single-file .NET 5 application that reproduces the case.
https://gist.github.com/SergioLuis/dd34d98dd72cbc102de01326ad701560

@phil-scott-78
Copy link
Contributor

Wonderful. If my little guy gets to bed at a reasonable hour I'll be able to take a look tonight I hope

@phil-scott-78
Copy link
Contributor

This has been a lot of fun messing with. Just submitted a PR with a huuuuuuuuuuuuge perf gain thanks to this - #552.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants