Sometimes the insertion of profiling instrumentation magnifies the cost of things in a hot loop or provides misleading hot spot info. If you're using a tracing profiler, you might try sampling instead as it's less prone to this.
Or, this sounds silly, but you can manually sample by just doing a few thread dumps while it's running (either ctrl-\ or externally with kill -3) and see what's at the top. If there really is a hot spot, this is a surprisingly effective way to see it. For this kind of code, there is no substitute for actually reading the bytecode and thinking carefully about where there is unnecessary casting or boxing. On Wed, Jan 30, 2019 at 6:55 PM Brian Craft <craft.br...@gmail.com> wrote: > I haven't tried much. I'm getting the java via clj-java-decompiler.core > 'decompile' macro. > > A long cast does drop the cast (which is really counter-intuitive: > explicitly invoke 'long', which calls longCast, in order to avoid calling > longCast). > > Amusingly this doesn't reduce the total run-time, though longCast drops > out of the hotspot list. :-p There must be some other limiting step that > I'm missing in the profiler. > > I'm calling it around 1.2M times, so hopefully that engages the jit. > > On Wednesday, January 30, 2019 at 3:39:41 PM UTC-8, Alex Miller wrote: >> >> What have you tried? And how are you getting that Java? I would prefer to >> look at bytecode (via javap) to verify what you're saying. >> >> Have you tried an explicit long cast? >> >> (aget flat-dict (bit-and 0xff (long (aget arr j)))) >> >> Are you running this hot enough for the JIT to kick in? Usually this is >> the kind of thing it's good at, but it might take 10k invocations before it >> does. >> >> >> On Wednesday, January 30, 2019 at 4:03:43 PM UTC-6, Brian Craft wrote: >>> >>> Profiling is showing a lot of time spent in RT.longCast, in places like >>> this: >>> >>> (aget flat-dict (bit-and 0xff (aget arr j))) >>> >>> arr is hinted as ^bytes, and flat-dict as ^objects. >>> >>> which compiles to this: >>> >>> Object code2 = RT.aget((Object[])flat_dict, RT.intCast(0xFFL & >>> RT.longCast((Object)RT.aget((byte[])arr2, RT.intCast(k))))) >>> >>> Is there any way to avoid that RT.longCast? There is an aget method in >>> RT.java that returns a byte, and a longCast for byte, but I suspect the >>> cast to Object is causing it to hit the longCast for Object, which does a >>> bunch of reflection. >>> >> -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to a topic in the > Google Groups "Clojure" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojure/vXJFuOujTaw/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
