Hey guys, The "small loss of performance expression" was applied to the specific example I used to illustrate the thing. 500 times longer may look huge but if it occurs 10 times in your application run, bottom line it may mean nothing.
Of course if you have a fn chewing up 30% of your application run time, reflection may become significant, hence the need to check. It was not meant as a general remark. It's a trade off situation and you must do some analysis to apply these optimizations. Most of the time here we do not care about the type of objects passed except in some frequently reused common code. We do not want to loose the flexibility of dynamic typing, our message bus runs on a small cluster Atom 330 machines 24/7... not Hulk like servers and we should be the rightly concerned by these optimizations. We did not find so many cases that justified retooling the code up to now. Luc P. On Wed, 19 Oct 2011 22:49:46 -0700 (PDT) Alan Malloy <a...@malloys.org> wrote: > I agree with the general sentiment: add typehints later, and only if > you need performance in this particular part of the code. I object to > the characterization as a "small loss of performance", though. A > reflective method call takes about five hundred times as long as a > hinted method call in the following benchmark, so if you do have a > performance-sensitive section of your program that needs to do a lot > of interop, the improvement is dramatic, not small. > > user> (time (dotimes [_ 1e6] (let [s (identity "test")] (.length s)))) > "Elapsed time: 15490.471302 msecs" > user> (time (dotimes [_ 1e6] (let [s (identity "test")] (.length > ^String s)))) > "Elapsed time: 34.561754 msecs" > > > On Oct 19, 10:35 pm, Luc Prefontaine <lprefonta...@softaddicts.ca> > wrote: > > Just use ^ for type hints. > > > > http://clojure.org/java_interop#Java%20Interop-Type%20Hints > > > > Type hints are used to eliminate reflection calls, the compiler can > > use the exact type of the parameter to eliminate the runtime cost > > of finding if methods/fields exist before calling/accessing them. > > > > user=> (set! *warn-on-reflection* true) > > true ;;; <== tells the compiler to complain about reflection calls > > user=> (defn a [b] (.startsWith b "a")) > > Reflection warning, NO_SOURCE_PATH:23 - call to startsWith can't be > > resolved. <=== Oups ! #'user/a > > user=> (a 1) > > java.lang.IllegalArgumentException: No matching method found: > > startsWith for class java.lang.Integer (NO_SOURCE_FILE:0) > > > > This definition has no type hint, the compiler flags a warning to > > say that it cannot resolve the method startsWith. If you try to > > call the first form with an object not implementing startsWith, the > > runtime traps that it did not find the method on that object's > > class. The flexibility comes with a cost, finding the method on the > > fly. > > > > user=> (defn a [^String b] (.startsWith b "a")) > > #'user/a > > user=> (a 1) > > java.lang.ClassCastException: java.lang.Integer cannot be cast to > > java.lang.String (NO_SOURCE_FILE:0) > > > > Here the compilation does not trigger the reflection warning, the > > argument type has been hinted as a string. The compiler can find > > the method immediately and generate the code without any runtime > > "search". > > > > At runtime, if you ever call the second form with a non string > > object, this time you get that the argument type is not the one > > expected (from the type hint). The compiler has added a type check > > instead of relying on the dynamic search for methods/fields in the > > class which is faster. > > > > Note that it's not data typing per se. You are allowed to call the > > form with a different object class. The compiler will not scream, > > the runtime will if you persists to call the method. > > > > Form #1 allows you to pass objects of any class that implements > > startsWith with a small loss of performance. In form #2 you can > > gain performance at the expense of generality. > > > > Type hints are to be to improve performance AFTER your code is more > > or less stable. If you use type hints early in your development, > > you will carry them all the way and that can be a significant pain. > > > > Luc P. > > > > On Wed, 19 Oct 2011 22:03:31 -0700 (PDT) > > > > > > > > > > > > > > > > > > > > mmwaikar <mmwai...@gmail.com> wrote: > > > Hi, > > > > > I read in "Clojure in Action" book by Amit Rathore, that #^ > > > associates metadata for the next form. He also mentions that it is > > > deprecated. So what is the current way of doing it? > > > > > Also, in code like this - > > > > > (defn filenames-in-jar > > > "Returns a sequence of Strings naming the non-directory entries in > > > the JAR file." > > > [#^JarFile jar-file] > > > > > is it specifying that the type of the jar-file argument should be > > > JarFile? > > > > > Where can I find some more documentation and or examples about it? > > > > > Thanks, > > > Manoj. > > > > -- > > Luc P. > > > > ================ > > The rabid Muppet > -- Luc P. ================ The rabid Muppet -- 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
