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 <javascript:>> > >> >> 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/groups/opt_out.
