Versions Compared

Old Version 6

changes.mady.by.user John Rose

Saved on

compared with

New Version 7

changes.mady.by.user John Rose

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Getting solid performance measurements is surprisingly tricky. Take extra care with micro-benchmarks.

See below for a list of relevant presentations and papers.

Here is another slice on the same information, from another angle: PerformanceTacticIndex.

Constants

  • Use constants when you can.
  • It's OK to store them in local variables; the SSA representation tends to keep them visible.
  • It's OK to store them in static final fields, too.
  • Static final fields can hold non-primitive, non-string constants.
  • The class of a static final field value is also constant, as is the array length (if it's an array).

...

  • Use a disassembler if available to inspect the generated code.
  • Switches are profiled but the profile information is poorly used. For now, consider building an initial decision tree if you know one or two cases are really common.
  • Exception throwing compiles to a goto, if the thrower and catcher inline together. For such uses, rely on preallocated or cloned exceptions, or override the fillInStackTrace part of exception creation, which is an expensive, reflective native call.
  • Do not use jsr/ret. Just clone your finally code if you have to.
  • If you are compiling a non-Java language, consider using standard mangling conventions.
  • If you are generating almost the same class many times in a row, with small variations, factor out the repeating parts into a superclass or static helper class.
  • For small variations in the remaining part, consider using a single named class as a template and loading it multiple times as an anonymous class with constant pool edits. Anonymous classes load and unload faster than named ones.

Presentations and Papers