You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Generally my thoughts are that this would be beneficial for Scala native and on the JVM.
As mentioned in the linked issue, the suggestion was to use keypool.
Here are some thoughts:
We don't really want it to be bounded, as the only issue with creating tons of these objects is just increasing the memory. Waiting for a free member would really suck.
I suspect that our idle lifetime for our various resources is dependent on the runtime. On scala native, it's pretty much going to be a malloc call so it's going to be fairly cheap - on the JVM, it's going to go through class reflection which is going to be a bit more expensive. Node delegates to OpenSSL so it will be the same as native unless they do something clever under the hood.
I'd also like to introduce some rudimentary benchmarking to see if it actually makes a difference.
The text was updated successfully, but these errors were encountered:
See typelevel/fs2#3157.
Generally my thoughts are that this would be beneficial for Scala native and on the JVM.
As mentioned in the linked issue, the suggestion was to use keypool.
Here are some thoughts:
malloc
call so it's going to be fairly cheap - on the JVM, it's going to go through class reflection which is going to be a bit more expensive. Node delegates to OpenSSL so it will be the same as native unless they do something clever under the hood.The text was updated successfully, but these errors were encountered: