Personally, optimizing for interpreter (or even C1) doesn't seem worth it. If something's truly hot and best perf is desired then use C2 or tiered. If the method isn't hot enough to trigger the C2 threshold, then why bother? You're already behind the 8 ball in terms of performance. Maybe this is heresy though :).
Sent from my phone On Jan 22, 2013 6:58 PM, "Ulf Zibis" <ulf.zi...@cosoco.de> wrote: > Am 22.01.2013 21:20, schrieb Vladimir Kozlov: > >> Thank you, Ulf >> >> I will rename method to encodeISOArray and add comment that it could be >> replaced by intrinsic by JVM. >> > > Thanks, that's much better. Thinking about, I would more like > encodeArrayToISO or just encodeToISO_8859_1. > > The same arrays were use intentionally in test to get performance of code >> without effect of CPU's cache/memory subsystem. >> > > I worry about, if the overhead of recalculating sp and dp + comparing ret > != len + complicated calculation of len will come to effect on short > strings, at least on C1 and interpreter. So why not choose the best code > for all these cases? > > The method encodeArrayLoop() is also compiled because it is invoked > >> 10000 times. >> > > That is what I assumed. > But I see 2 corner cases: > - Programs with sparse use of ISO-8859-1 encoding will not profit of it, > if the compile threshold becomes not reached. Also think about C1. > - I worry, that on small strings the performance of the the intrinsic > surrounding code would come to some account, even if JIT-compiled, but > specially on C1 and interpreter. > So would it hurt, to include those cases while tuning? > > -Ulf > >
