I do:
(let ((meth (jmethod "java.lang...." "javaMethodName" "arg-type")) (cls (jclass "java.lang....."))) (defun lisp-fun (arg) (jcall meth cls arg)))
Rather than:
(defun lisp-fun (arg) (jcall (jmethod "java.lang...." "javaMethodName" "arg-type") (jclass "java.lang.....") arg))
In order to cache the jmethod and jclass calls. I read in another post that this had no value because (essentially) this is what the compiler is doing anyway. Is this true? Does it make any difference which way I do it in terms of speed?
Thanks.
Blake McBride
On Tue, Feb 16, 2010 at 2:59 AM, Blake McBride blake@mcbride.name wrote:
I do: (let ((meth (jmethod "java.lang...." "javaMethodName" "arg-type")) (cls (jclass "java.lang....."))) (defun lisp-fun (arg) (jcall meth cls arg))) Rather than: (defun lisp-fun (arg) (jcall (jmethod "java.lang...." "javaMethodName" "arg-type") (jclass "java.lang.....") arg)) In order to cache the jmethod and jclass calls. I read in another post that this had no value because (essentially) this is what the compiler is doing anyway. Is this true? Does it make any difference which way I do it in terms of speed?
AFAIK, the compiler already caches the class and method metaobject on a per-call-site basis, obviously only if it knows at compile time all the parameters to the jcall/jmethod call. I'd like eventually to make the compiler even smarter and generate directly the bytecode to invoke the method if it has all the information to do so; this means that in the future it might be actually more efficient *not* to cache methods and classes! (*if and only if* everything is known at compile time i.e. all the arguments to jmethod/jclass are constantp). For all the other cases - in interpreted code, or when the arguments are variable and not entirely known at compile time - caching methods and classes is useful performance-wise.
Cheers, Alessio
armedbear-devel@common-lisp.net