-
Notifications
You must be signed in to change notification settings - Fork 39
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 of calling socket worse than lens #491
Comments
How did you go about benchmarking this? It would be great to reproduce this on my own machine as well. |
Click boots up an instance of |
I did a benchmark in this repo (https://github.com/guaraqe/urbit-benchmark), these are the results:
The repo contains click, and two scripts, one running with click, another with lens. The first argument to @mopfel-winrux I measured locally, and the calls to |
@guaraqe Do you have the numbers on hand for the time just to boot up the transient instances of Vere to jam/cue the noun? If not, it should be easily testable by writing a script to jam an atom using Vere, and directly pipe the result to another transient instance of Vere to cue it. We might also want to test with a non-trivial noun (e.g. an entire inline thread). The above isn't directed at anyone in particular; just wanted to note down the idea for benchmarking time with transient Vere instances independent of the socket. |
I added a case with just calls the
If we subtract, that would be around 130ms for the socket, which is still 4x more. This difference is more visible for @ashelkovnykov I marked you in a private issue with more details. |
Theres also a cue that gets called which would take just as long as jam |
Yeah, I removed it twice from the total to get to the 130ms. |
Isn't this just an account of the extra time required for compiling the threads? |
That sounds right. There's already a |
When doing similar operations (such as getting the ship's code or the output of vats) both by talking via HTTP with lens, or by running a thread via socket, the performance of the socket is consistently worse, being around 2x slower than lens. I checked, and when using the socket method, most of the time is spent by waiting for the output of
recv
, so this seems to be something internal to Urbit.Is this performance difference expected?
The text was updated successfully, but these errors were encountered: