-
Notifications
You must be signed in to change notification settings - Fork 22
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
Add ':binding' support #55
base: develop
Are you sure you want to change the base?
Conversation
Addressed the cleanup items from my previous commit. |
Per metosin#54 in metosin/seippari, this commit could be considered a starting point for supporting bindings support in clojure. The initial implementation used the starting point @robert-stuttaford posted in the referenced issue. A tradeoff here, is that in order to support sync/async w/ the various runtimes, using (bound-fn*) seems to be necessary given the different thread pool implemenations. Counsequently, there is a a perf hit needing to push/pop thread local vars. It doesn't seem to be too much in the general case, but with manifold, it seems to a an order of magnitude slower, though still in the microseconds.
@jarppe, pinging here since (from my vantage point), it looks like you're the maintainer. If ya'll would like the contribution, what is your take on these changes? |
This is largely a port of @bnert's PR for sieppari ref: metosin/sieppari#55 The caveats from that PR regarding a small hit to performance, probably apply, though I did not do any benchmarking since the repo isn't setup for it.
I asked the folks over at exoscale/interceptor if they would be interested in adding this feature, but they were not (understandably given their scope statement). This leaves sieppari as the only other extant independent interceptor implementation. This feature is needed when trying to interceptorize existing middlewares. |
Overview
Per #54, this commit could be considered a starting point for supporting bindings support in Clojure, not ClojureScript, given the platform differences.
The initial implementation used the starting point @robert-stuttaford posted in the referenced issue.
Performance Tradeoff
A tradeoff here is in order to support sync/async w/ the various runtimes, using
(bound-fn*)
seems to be necessary given the different thread pool implemenations. Counsequently, there looks to be a slight performance hit needing to push/pop thread local vars in the general case. However, manifold seems to a an order of magnitude slower, though still in the microseconds.Not sure the tradeoff ya'll at metosin want to make here. I'll throw in my 2 cents, in that if manifold is being chosen as the async executor, it isn't being chosen for raw performance.
Perf Tests
I ran the following on:
Results of `lein perf-test` before changes
Results of `lein perf-test` after changes