Allocation reduction pass

[JakeWharton]

Just a reminder to do a normal allocation-reduction pass for free performance wins, even if minute.

• Switch loops to be indexed when we can trust the source of the list to be random access.
• Replace multi-step collection manipulation with traditional loops.
• Reduce/eliminate points of value class or JVM primitive boxing, if possible
• Try to use specialized androidx.collections

etc.

[EpicDima]

I wanted to ask, are we doing optimizations right now, while there probably aren't any critical performance problems, and the actual question is, isn't this premature optimization? If not, why not? I like this, but it's interesting to get an opinion on this 😊

[JakeWharton]

Yeah it's a good question. I have a few opinions on it:

• Speed is a feature.

  Computers felt faster 20 years ago then they do today because abstraction and indirection has outpaced all variants of Moore's law (clock speed, core count, cpu cache size, cpu cache speed, etc.). Fast things feel good, and I want this to be as fast as possible.

• We are the inner loop of applications.

  Someone using an iterator-based loop instead of an indexed-based loop in a Mosaic application is probably not a big deal. Us using an iterator-based loop instead of an indexed-based loop in code that runs on every node occurs multiple orders of magnitude more, which means it has multiple orders of magnitude greater.

  Micro optimizations reducing CPU, memory, or I/O within the library become a macro optimization because we do it at 1000 FPS or within 1000 nodes (or both!).

• It's not that hard!

  Kotlin gives us plenty of tools to allow efficient things to remain expressive. It's not a huge sacrifice as opposed to some other languages. We aren't losing guardrails, we're becoming sympathetic how the machine works.

I've had a lot of success doing this in the past, and generally try to do it in libraries everywhere.