High Performance App Architecture
updated 10 months ago; latest suggestion 9 months ago
Application performance is often seen as a little bit of tuning done near the end of your development cycle, with the assistance of tools like Instruments.
In fact, there is a catchy quote by the Obi-Wan of Computer Science, Don Knuth to back this up: "Premature optimization is the root of all evil." However, that quote, often even shorn of the word "premature", is only the second half of the actual sentence, the first goes: "We should forget about small efficiencies, say about 97% of the time".
Application architecture is about the big efficiencies, the ones that make or break your application. How you structure your application, how you think about storage, how the parts of your application communicate will determine how your app performs, whether your app annoys its users or performs beautifully. It will also determine whether you spend the end of your development cycle chasing ever more elusive performance goals or either no longer worrying about performance at all or at most catching a few minor issues using the tools.
Using case studies and measurements, I will show common pitfalls in performance architecture, how these pitfalls illustrate underlying principles, and last not least techniques for applying those principles in order to get both excellent performance and simplicity.
More Knuth (from the same paper):
"The conventional wisdom shared by many of today's software engineers calls for ignoring efficiency in the small; but I believe this is simply an overreaction to the abuses they see being practiced by penny- wise-and-pound-foolish programmers, who can't debug or maintain their "optimized" programs. In established engineering disciplines a 12% improvement, easily obtained, is never considered marginal; and I believe the same viewpoint should prevail in software engineering. Of course I wouldn't bother making such optimizations on a one-shot job, but when it's a question of preparing quality programs, I don't want to restrict myself to tools that deny me such efficiencies."
As proposed, this reads a lot like "go read Knuth's paper" which makes it a hard sell as a talk to attend. I agree about the time issues, and like the idea of focusing on a single case study - the techniques used to identify it, why this is a case where the "premature optimizations" made sense, and what the solutions ultimately looked like (not necessarily in code, but even from an abstract, algorithmic view, unless they were very targeted and simple changes.)
Yeah, this seems like a monster topic to cover in 30 minutes. I wouldn't get bogged down in languages at all. Were this something I was considering, I might pick a single example where the choice of the wrong algorithm meant that micro-optimisations led to only small improvements, but the choice of an entirely different (perhaps less obvious algorithm) led to a substantial improvement.
That could probably fit into 30 minutes.
I'm afraid if you try to do too much of a survey of architecture ideas, you won't cover much. You can't possibly cover a semester's worth of algorithms in 30 minutes. I think the goal should be to plant the seed: sometimes we need to completely re-think the way we're doing things rather than look for small ways to improve it.
Yes, though with UIKonf talks being only 30 minutes it won't be able to go into too much depth on the language aspects without negatively impacting the architectural view.
Will this talk involve language specific issues? e.g Obj-C vs. Swift performance?