I know this is an old thread ... but FWIW I think this is awesome. Great work, Michael! I am going to play around with it.
On Thursday, March 28, 2013 10:31:00 PM UTC-7, Michael Cohen wrote: > > I ran a quick and dirty benchmark comparing Amazonica with James' rotary > library, which uses no explicit reflection. This was run from an EC2 > instance in East, hitting a Dynamo table in the East region. tl;dr > Amazonica averaged 9ms for gets, rotary averaged 6ms, both averaged 13ms > for puts. Summary is at https://github.com/mcohen01/amazonica#performance. > Benchmark code is at > https://github.com/mcohen01/amazonica-benchmark/blob/master/test/benchmark/runner.clj > . > > It's pretty simplistic, but I just wanted to see if reflection just > completely turned the library into a dog. Seems the contrary, that any > reflection performance penalty is basically not even worth mentioning. > Maybe some folks who have better understanding of jvm internals can explain > if the test is invalid because of some sort of caching of the method > lookups or something. > > > On Wednesday, March 27, 2013 7:29:00 AM UTC-7, Herwig Hochleitner wrote: >> >> 2013/3/26 Hugo Duncan <dunca...@gmail.com> >> >>> >>> Or can the cost be confined to compile time... >>> >> >> That would be nice to have! >> Generating type-hinted clojure code from the reflection result and >> emitting that with macros would be an option. >> >> I think the dynamic use of reflection would be enough to put me off >>> using this in something like pallet, for example. >>> >> >> I agree with Michael on this: Any reflection overhead should pale next to >> the context switch and network communication, that AWS commands do. >> OTOH, I also agree that driving a generated java api via reflection, to >> generate xml seems a bit heavy handed. >> Still, first priority should be to get the interface right. >> >> Regarding that: I think the first context argument should be mandatory. >> We are just saw clojure.java.jdbc painstakenly deprecate a lot of API, to >> get rid of the dynamic *db* var. >> The reasons against passing context in a dynamic var go double against a >> global atom: A function parameter can be set at from any data model in >> every callsite. Everything that's less flexible constrains your users for >> little gain (in the case of passing context). >> >> Also, my experience with ClojureQL showed me, that with multiple sources >> of a context arg, it's hard to get the ordering right. >> E.g. the new implementation seems to prefer dynamically bound credentials >> over credentials passed as argument. >> >> -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
