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?
>
>