-
Notifications
You must be signed in to change notification settings - Fork 27
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
Performance? #302
Comments
It's also possible I'm rendering very inefficiency. lol |
Hi, I don't have any metrics to hand, but I do know that Vedeu is capable of refreshing only parts of the screen at a time, but this is dependent on which refresh event is called and basically how you have it set up. By using the
This results in log entries which will look similar to You can try this in your code; with varying degrees of success dependent on which context (binding) you are currently operating under, i.e. if you are using the DSL, it might be a bit problematic, but if you wrap a method or method calling a class then you should get something meaningful back. If you have a repository with code using Vedeu, (which I think you do- https://github.com/NullVoxPopuli/spiced_rumby) point me to the classes which you think are slow and we can work together to either improve Vedeu or your usage of it. Would you like me to take a glance at a particular branch of the aforementioned repository and see if I can spot anything/create a pull request for anything that I think could be changed to better suit how Vedeu works? As an aside, the biggest problem for me with Vedeu is documentation; I intrinsically know how it works, what calls what, and translating this into something for developers such as yourself to use is incredibly (for me) difficult. But! I am willing to keep trying :-) |
Thanks for the help! I made some changes as to when I'm rendering last night which seemed to improve performance on my laptop. However, on my VM, things are still slow. It appears as though the input box I'm tying in to is getting entirely redrawn every time I type a letter?
Is there a way to not have it re-render and just append the character? |
Removing the cursor related stuff from the log (which is admittedly noisy (will be tamed)), we're left with a log that looks like this:
Although the Compression times are still a bit slow, they are still approximately > 100fps. This makes me wonder if there is an issue around the Stay tuned, and thanks :-) |
thank you :-) |
Running this on my machine reports much slower times than your log suggests. I typed a sentence as fast as I could and noticed missing characters (never good). For a random character pressed, I took the section of the log file and removed the mouse events. I then annotated that log file as below:
This snippet represents 49.1ms of time, with 44.0ms of unaccounted 'stuff' going on (between 2726.5872 and 2726.6312. The plot thickens. |
lol. I believe in you! |
Despite spending a couple of hours this evening with this, I'm regretful in only being able to provide the most unhelpful of responses so far.
Notebook maths not being my strongest subject, I did make an interesting observation:
The conclusion of the above, is that I need (somehow) to make Vedeu twice as quick. Challenge accepted. :-) Thanks and stay tuned. |
A side note; disabling compression yields around twice as much data being sent to the terminal; e.g. 7280 objects becomes 122894 characters. With compression, 7280 objects becomes 72260 characters. The mechanism for compression is rudimentary at best, so this is where I will focus my efforts. |
Thanks for the report! I love hearing about all these stats. |
Compression is achieved by not repeatedly sending a position when only the x coordinate has changed; i.e. we are on the same line, just advancing a character. In the test application, we have gone from sending 72260 characters to the terminal to just 13971- approximately 80% reduction. Reported compression time has changed from average 20.6ms to 13.2ms- a ~35% improvement. Also, add more documentation. Work related to #302.
Upon further analysis, I have discovered whilst rendering the 7280 objects, that on average, cumulatively, 7.7ms is spent converting The optimisation of this could reduce the compression time to half of that reported in 39adab0 (~13.2ms -> 5.5ms in the best case scenario). We're getting somewhere! |
woo! |
This allows us to then fetch the respective interface for the Char, which should make colour/style fetching faster. Work relating to #302.
Note: Stream will try to access Line, and Line will access the parent view. Work relating to #302.
Compression is achieved by not repeatedly sending a position when only the x coordinate has changed; i.e. we are on the same line, just advancing a character. In the test application, we have gone from sending 72260 characters to the terminal to just 13971- approximately 80% reduction. Reported compression time has changed from average 20.6ms to 13.2ms- a ~35% improvement. Also, add more documentation. Work related to #302.
In Presentation::Colour and Presentation::Styles, a check has been added for whether we are dealing with a Vedeu::Views::Char- if so, then we can use the '#interface' method of that class to get the colour information instead of the slower '#parent' route. Work relating to #302.
Rather than redraw the whole screen on a document character change we update the buffer and redraw only the document area. Fixes #302.
Apart from some other optimisations around the compressor as detailed previously, I've take a small step to refresh only the view which changed when using :fake_mode for a view (i.e. an editor). Do you want to have a play with the result, and if you're happy with this particular aspect of performance, we can close this issue. If there are other aspects you'd like to address, shall we open a new issue(s) for those? Hope this helps, and thanks for using Vedeu :-D |
thanks for working on this! I actually re-installed Ubuntu on my VM (now at 15.10), and that alone made things a little faster.
it looks like I'm using so, when typing just a visual thing though, it still looks like the input is re-drawing on every input - not sure if you tried to address that or not -- or even if it is addressable. |
I 'think' that vedeu appears to re-render the whole screen whenever refresh or a render is called,
it appears that curses can somehow manipulate just a portion of the screen at a time (at the loss of color depth, and less characters (no utf8)
Do you have any metrics / examples of speed of vedeu compared to libraries such as dispel or canis? (or just raw curses)?
The text was updated successfully, but these errors were encountered: