Well, of course everything is handled via reflection, which has a cost. The question is, can you afford the cost. In general, I think most of the AWS apis really aren't concerned with performance, e.g. EC2, and you're not making (many) repeated calls. If you look at something like DynamoDB though, that might be a case where you're quite concerned with performance, and potentially making numerous calls. Of course these calls are remote calls, so I'd guess that the reflection penalty is much smaller than the price you pay going out of process. As with anything though, measurement is key. I actually planned on doing some kind of benchmark comparison against Jame's excellent rotary <https://github.com/weavejester/rotary>. In general though I think for AWS reflection would not be an issue.
On Tuesday, March 26, 2013 11:23:29 AM UTC-7, tbc++ wrote: > > I'm a bit concerned about all the reflection going on. Am I correct that > the lib does dynamic dispatch at runtime based on both the arity and the > number of arguments? The code looks like it would be painfully slow. > Perhaps the hit is okay if I only want to make a dozen calls a second or > so, but if I wanted more performance it seems like this library would cause > me some problems. > > Besides that, I love the idea of an auto generated lib. > > Timothy Baldridge > > > On Tue, Mar 26, 2013 at 12:18 PM, Michael Cohen > <mcoh...@gmail.com<javascript:> > > wrote: > >> Thanks for the comments. I've made the suggested changes such that the >> AWS functions take an optional first parameter map of credentials. But I'm >> left wondering if it should not be required, and just do away with the >> stateful "defcredential" convenience. Thots? >> >> >> >> On Monday, March 25, 2013 6:29:49 PM UTC-7, Herwig Hochleitner wrote: >>> >>> 2013/3/26 James Reeves <ja...@booleanknot.com> >>> >>> It looks very interesting, but I'm afraid I really don't like >>>> "defcredential" macro. The Clojure API should really have *less*mutability >>>> than the Java API, not more :) >>>> >>> >>> Agreed! It would be nicer to pass a context to the api functions. >>> >>> The api functions could be generated such to expect an optional first >>> context argument and otherwise expect a dynamic binding. >>> IMO it would also be acceptable to unconditionally take a context >>> argument, because we have doto. >>> >> -- >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@googlegroups.com<javascript:> >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com <javascript:> >> 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+u...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > > > -- > “One of the main causes of the fall of the Roman Empire was that–lacking > zero–they had no way to indicate successful termination of their C > programs.” > (Robert Firth) > -- -- 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.
