* Re: Profiling Kawa code [not found] <CAMFYt2Y3s-z-bW=2D06qxHc-CB55GXH_f5G89GbXCqUHCW-BOw@mail.gmail.com> @ 2023-10-07 1:18 ` Panicz Maciej Godek 2023-10-07 3:54 ` Per Bothner 0 siblings, 1 reply; 3+ messages in thread From: Panicz Maciej Godek @ 2023-10-07 1:18 UTC (permalink / raw) To: kawa [-- 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? > > ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Profiling Kawa code 2023-10-07 1:18 ` Profiling Kawa code Panicz Maciej Godek @ 2023-10-07 3:54 ` Per Bothner 2023-10-07 3:57 ` Per Bothner 0 siblings, 1 reply; 3+ messages in thread From: Per Bothner @ 2023-10-07 3:54 UTC (permalink / raw) To: Panicz Maciej Godek, kawa 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/ ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Profiling Kawa code 2023-10-07 3:54 ` Per Bothner @ 2023-10-07 3:57 ` Per Bothner 0 siblings, 0 replies; 3+ messages in thread From: Per Bothner @ 2023-10-07 3:57 UTC (permalink / raw) To: Panicz Maciej Godek, kawa 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/ ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2023-10-07 3:57 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CAMFYt2Y3s-z-bW=2D06qxHc-CB55GXH_f5G89GbXCqUHCW-BOw@mail.gmail.com> 2023-10-07 1:18 ` Profiling Kawa code Panicz Maciej Godek 2023-10-07 3:54 ` Per Bothner 2023-10-07 3:57 ` Per Bothner
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).