Re: Profiling Kawa code

Re: Profiling Kawa code

[Panicz Maciej Godek]

[-- Attachment #1: Type: text/plain, Size: 2027 bytes --]

I did some profiling using VisualVM.
First, it turned out that the slowdown came from a combinatorial explosion
in my equality checking function.
The complexity is now tamed, and the behavior is consistently smooth on the
PC, but it still skips frames on Android.

I made an optimization (memoization) to avoid repeated computation of the
same thing in the rendering loop, because I was suspecting that to be the
main source of complexity.

According to the profiler the things did improve a bit, but the app still
works noticeably slower than the one written in Java.

The results of running a profiler show that:
13% of time is spent in java.lang.reflect.Method.invoke
24% are spent in various graphics API functions
8.4% is spent in gnu.lists.AbstractCharVector.hashCode
5.7% is spent in java.lang.Class.getDeclaredMethod
5.1% is spent in gnu.kawa.functions.IsEqual.match

it seems that reflection uses over 18% of total time, and I think it would
be great if this overhead could somehow be removed
(I don't think that the design of GRASP requires any reflection, so it's
possible that I'm misusing Kawa in some ways)


pt., 6 paź 2023 o 11:16 Panicz Maciej Godek <godek.maciek@gmail.com>
napisał(a):

> Hi,
> As some of you may know, I've been developing a visual editor for
> s-expressions.
> Currently it's written 100% in Kawa (except some shell scripts that are
> used for building and running). But I've noticed that it performs worse
> than the earlier prototype, that was written in Java.
> That's especially visible when I run it on my Android phone, whose
> computational power is limited. But even on my super-fast laptop (9th gen
> core i7) I see it occasionally choking.
>
> For example, I recently added a "visual stepper", and I ran it on the
> Ackermann function. It generally runs smoothly, but around 1:28-1:35 it
> suddenly slows down:
>
> https://youtu.be/1sB8fA-4S80?feature=shared&t=87
>
> So my question is, how do I approach profiling this code?
>
>

Re: Profiling Kawa code

[Per Bothner]

On 10/6/23 18:18, Panicz Maciej Godek via Kawa wrote:
> it seems that reflection uses over 18% of total time, and I think it would
> be great if this overhead could somehow be removed
> (I don't think that the design of GRASP requires any reflection, so it's
> possible that I'm misusing Kawa in some ways)

I don't remember exactly when lang.reflect.Method.invoke is called.
One place is when you try to call a Java methid (perhaps with the
invoke procedure) but the compiler can't resolve it to a specific
method (or virtual method).

You need to figure out where in the generated bytecode Method.invoke
is called. You can use javap or some other bytecode de-compiiler
or dis-assembler. Once you narrow down wheer the call is coming
from you can add type specifiers to help the compiler.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: Profiling Kawa code

[Per Bothner]

On 10/6/23 20:54, Per Bothner wrote:
> You need to figure out where in the generated bytecode Method.invoke
> is called. You can use javap or some other bytecode de-compiiler
> or dis-assembler. Once you narrow down wheer the call is coming
> from you can add type specifiers to help the compiler.

Your profiler tool can probably also help you figure out the *caller* of Method.invoke.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/