[armedbear-devel] It it worth cacheing jmethod and jclass calls?

Alessio Stalla alessiostalla at gmail.com
Tue Feb 16 08:32:04 UTC 2010

On Tue, Feb 16, 2010 at 2:59 AM, Blake McBride <blake at 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.


More information about the armedbear-devel mailing list