Slow performance?

[Andersama]

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]

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

[Andersama]

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

[Andersama]

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:

zep/src/mode.cpp

Line 436 in 2ff7e62

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]

You're testing a release build, right?

[Andersama]

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]

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]

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]

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.

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

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:

[Green-Sky]

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

[Andersama]

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

[HKS5]

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.

[shmolyneaux]

Just to add on to this, it feels like keys are being processed on key up, rather than on key down. That may be the source of some of the perceived delays.

Edit: I updated demo_imgui/main.cpp to use a while loop for the input events and it feels way better:

        SDL_Event event;
        while (SDL_PollEvent(&event))
        {
            ImGui_ImplSDL2_ProcessEvent(&event);
            if (event.type == SDL_QUIT)
                done = true;^M
            if (event.type == SDL_WINDOWEVENT && event.window.event == SDL_WINDOWEVENT_CLOSE && event.window.windowID == SDL_GetWindowID(window))
                done = true;
        }
        // else removed