Design Philosophy
In an earlier epoch I designed embedded system hardware and software in two different areas:
- Pro Audio
- Digital Signal Processing
Both of these fields are 'real-time' programming. It's not dissimilar to what you have to deal with in Unity3D:
-
A frame in pro audio at 44.1 kHz doesn't allow much time per-sample to process much, about 22 microseconds.
-
A frame in a game at 60 Hz is about 17 milliseconds which sounds quite generous by comparison.
Either way, you have a certain amount of time to do your processing or:
- Audio ==> Artifacts
- Game ==> Dropped frames
For audio, back in the day, normal PC processors were way too slow to process even audio. Hence we had DSP (Digital Signal Processing) chips from TI, AT&T, and others.
There were no development tools for these chips, do our company (read: me) developed them. Pretty highly regarded: I rewrote one in Objective-C for the a released debugger shipped with the original NeXT machines.
Anyway, coding DSP chips was difficult. It was all machine language with exposed pipelines in some cases.
Exposed Pipeline: operations don't execute in the order that you write them, Fun!
Fun Reading An early DSP chip spec sheet.
Hence, at 100 or 200 ns per instruction you just could not execute all that many instructions in one frame. So you had to code with performance as #1. You could never write code that wasn't fully optimized for perfomance from the start because you couldn't even test it. And debugging was guesswork (no tools at first).
This is all to say that this biased my approach to coding.
So I tend to eschew the modern programming idiom of write first optimize later.
- Use generics where it makes sense (to me), such as in the
MessagingService's messages. - Tightly hardcode things that by nature have to be optimized, such as the Tweener service and the internals of TpLibTasks.
- Extensively pool class instances and other objects.
- Extensively cache tile instances in the layout system.
No acronym-based coding style will be found anywhere :-)