-
Notifications
You must be signed in to change notification settings - Fork 157
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
Use publish / subscribe architecture. #465
Labels
Comments
For comparison, I think LeoPyRef.leo has only 7800 nodes, so a minuscule impact typically. |
On Sun, Apr 2, 2017 at 3:46 PM, Terry Brown ***@***.***> wrote:
This is really just a placeholder for some research.
An excellent use of a git issue, imo.
Twenty trials with and without the signal emission, mean 1.3 sec without,
1.4 seconds with, 8% slowdown. But I think it's important to emphasize that
this is 8% on a very fast (76,000 nodes per second) operation. So it's not
8% on the load time for a file, it's 8% on a very short subset of the load
time for a file.
Seems fine to me. For more accurate results, consider using the timeit
module <https://docs.python.org/2/library/timeit.html>. Somewhere there is
a humorous quote that using timeit allows one to investigate code that will
have negligible performance impact so that one can move on :-)
Edward
|
While trying to find the quote, I ran across this stack overflow answer. I thought the fourth answer (starting with "I'll let you in on a secret: the best way to use timeit is on the command line.") was the most interesting/surprising. |
This was referenced Mar 11, 2018
This will not happen unless Terry does it. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is really just a placeholder for some research.
For the Leo Editor Pane development I've tested a publish / subscribe architecture, or signal / connect architecture. It includes an experimental emission of a signal from v.setBodyString(). I tested the performance impact with this code:
Twenty trials with and without the signal emission, mean 1.3 sec without, 1.4 seconds with, 8% slowdown. But I think it's important to emphasize that this is 8% on a very fast (76,000 nodes per second) operation. So it's not 8% on the load time for a file, it's 8% on a very short subset of the load time for a file.
The tests had really high variance (ranges of 0.99-2.91 and 1.07-2.38 respectively), which seems strange. Observed on two different machines - something to do with dynamic CPU clockspeed adjustment maybe?
The text was updated successfully, but these errors were encountered: