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

Slow performance? #114

Open
Andersama opened this issue Aug 26, 2023 · 11 comments
Open

Slow performance? #114

Andersama opened this issue Aug 26, 2023 · 11 comments

Comments

@Andersama
Copy link

Describe the bug
I was curious so I grabbed the release page to check out the editor. I'm finding that all my keystrokes take just a bit long to register, I'm not sure what the metric is for feeling as if typing is smooth and responsive, best I can tell maybe there's something like a fraction of a second delay. I'm not sure why, I haven't built the source code to profile, but I figured I should make a note of this. It's just enough to be disorienting to type when looking at the screen.

@cmaughan
Copy link
Collaborator

I haven't noticed this; it should be pretty quick on release build. I will have a play.

@Andersama
Copy link
Author

I'll try building and profiling it at some point.

@Andersama
Copy link
Author

Andersama commented Aug 28, 2023

Well, I'm not sure how the project's organized, seems like it's set up to potentially build the demo along with the library at the same time. Haven't figured out how to launch the demo with the debugger yet, but having built the demo I'm getting the same kind of delay.

Edit: I figured out how to build and debug the demo, when I hit keystrokes I get very tiny but noticeable spikes, sort of what I'd expect out of a gui, however* when I dig down, the majority of that spike is this line:

auto spContext = std::make_shared<CommandContext>(m_currentCommand, *this, m_currentMode);

It could be that my system's struggling with very small allocations for dealing with shared_ptr and strings everywhere.

@cmaughan
Copy link
Collaborator

You're testing a release build, right?

@Andersama
Copy link
Author

Andersama commented Aug 28, 2023

Yes, although to be fair, since MSVC is a sampling profiler the issue could be anywhere really in those functions because the assembly's shuffled around. It could be the other parts of the code in that area potentially to do with switching modes or processing commands.

    // The current command is our currently typed multi-key operation
    m_currentCommand += input;

I'm not familiar with vim commands and editors, the way your comments read it sounds like you're doing a lot of manipulations on strings because you may need to replay keystrokes. Unfortunately whatever's taking that fraction too long doesn't stick out in the performance profiler well, I'm not always getting for example that line being the issue.

@cmaughan
Copy link
Collaborator

I tried a quick profile and the time in Zep seems minimal on my machine; certainly nowhere in the keyboard code. That matches my experience when live coding with the tool; I don't feel like I'm waiting for it any more than any other editor.
I am happy to believe that some (much) of the code is unoptimized; but I guess I need a more obvious place to improve than what I'm currently seeing (and a reason to do it!)

It is true that Zep records keystrokes for replay; as you say, the dot command in Vim requires it. But it shouldn't really be a big deal pushing a bunch of characters into an array, or storing undoable commands. I have some profiling code I use in the sister VKLive project; which I could probably pad out in Zep to see where the time is going...

  • Obviously it helps if you are not synced to VBlank, but the demo does that for you.
  • A release build is essential, because some of the STL structures are slow on debug, and I have my own checks too.
  • Editing bigger files might be an issue - not sure if you are editing anything in particular?
  • Unicode isn't much tested.
  • Of course, on a slower machine, things might be different.
  • It would be good to compare with the Qt build to see if that makes a difference.

@cmaughan
Copy link
Collaborator

There's a bit of editing with Zep being done here (you can see my tweaking things on the left when the video gets going):
https://www.youtube.com/watch?v=xhLqLdcjmPk

Or here in an overview video:
https://www.youtube.com/watch?v=mebNIQt8pKE

Subjectively, does this look faster than your experience? I know it may be hard to judge....

@Andersama
Copy link
Author

Andersama commented Aug 31, 2023

Without a frame of reference for when you input a keystroke it's hard to say, but both videos look smoother me. I'm sure there'd be a way to add a timer from when the keystrokes are received to after they're processed.

Edit: It hit me that windows has keyboard options for repeating keys etc. I lowered the delay to what appears to be the minimum option. That did seem to make an impact for holding keys, however, it didn't make difference for when I'm typing normally.

For whatever reason I don't know why the onscreen windows keyboard doesn't show all the keys being pressed, but here's an example, I'm pressing shift+ a key as tightly together as I can. There's a capturable delay between when the onscreen keyboard registers my shift and when the letter appears in the editor.
ZepDemo_gcTQmdqxnO

I'm double checking my capture settings, I think that first one was 30 fps capture, with 15 fps playback in the gif.

ZepDemo_ah3rUXVdu6

This one should be 30 fps captured and 30 fps playback I think...hopefully, so this one I think shows what I'm dealing with.

For comparison's sake, here's what it's like in MSVC:
devenv_RU4VsVD77P

@Green-Sky
Copy link
Contributor

can you check weather double- or triple-buffering is enabled? (vsync)

@Andersama
Copy link
Author

I'm not sure how I'd check other than in code, it looks to be hardcoded to be disabled.

@HKS5
Copy link

HKS5 commented Nov 23, 2023

The performance seems to be relatively slow for me aswell when comparing to some tools like VS Code. Zep seems to struggle when you have big file loaded. Viewing the files is smooth but here is few things i experienced:

  • Frames dropped to around 1-10 when writing into file with over 10k lines.
  • Same frame drop happens whenever the position of the editor changes.

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

4 participants