Application Performance and
The Trap of Object-Orientedness
Targo Tennisberg
Development Manager and Self-Proclaimed Guru
http://www.targotennisberg.com/tarkvara
September 2008
Trap of Object-Orientedness
Tenets of OOP: abstraction, encapsulation, inheritance
and polymorphism
OOP is good and makes us more productive
It also reduces our level of understanding about the
underlying components
Ideally, we’re not supposed to know what’s inside a wellencapsulated component
Reality is not quite so simple
Super easy to misuse technology
Grandma sending you a 500 MB video by
drag & drop
Programmers make the exact same mistakes!
Civil Engineering Analogy
If builders built buildings the
way programmers wrote
programs, then the first
woodpecker that came along
would destroy civilization
(Weinberg’s second law)
Every civil engineer knows the
basic properties of the
materials he is working with
Imagine building a skyscraper
out of “encapsulated”
components
It’s common for software
engineers not to know the
algorithms and behaviors of
their underlying components
Example: OR Mappings
Classic task: ObjectRelational impedance
mismatch
Many different frameworks
between the app and DB
Mappings tend to make
things complicated and
imperfect.
Application
.Net/Java classes
O-R Mapper
((N)Hibernate, LINQ,
Application Servers)
SQL
Database
Case Study: SharePoint, part 1
Special Case of an OR-Mapper
Documents, lists, web parts etc stored in a database
Thin .Net object model translates API calls to SQL
Simple APIs
New developers tend to call lots of methods
All of them result in a more or less complex SQL query
Typical symptoms include:
Acceptable performance on developer’s machine
In actual deployment or stress test, operations exhibit random slowness
or blockages
SQL CPU/memory often very high
No single obvious problematic query, things are sometimes faster,
sometimes slower
Usually a sign of the “Estonian Customs” application model
“Eesti Toll” application model
No central concept of what data
we require
Whenever anything is needed, a
new query is executed
Lots of “chattiness” and extra
data is sent over the wires
Same data is sent many times
Death by a thousand cuts
OK for prototyping or certain low
risk areas, but highly dangerous
in real life applications
Case Study: SharePoint, part 2
Reducing the number queries became the holy grail
Every query examined: do we need it?
Combining strategy
Data Sharing strategy
Caching strategy
Think about how often data actually changes
Various invalidation algorithms
Query police: specific tests for number of queries, developers had to
defend the need for them to an architect
Result: Sharepoint Portal Server 2003 had only two DB queries in
order to render the portal homepage
In comparison: many custom SharePoint developments have 30+
queries/page
Can lead to the “Doctor’s Office” application model
“Perearst” application model
Many little caches all over the
place, just like the lines in a
doctor’s office
Can create memory pressure
Significant improvement over
the “Eesti toll” model
Often sufficient
Many caches can be redundant
SQL, ADO, your favorite
framework already cache some
stuff
Case Study: SharePoint, Part 3
Cut out as many data transformations and stages as
possible
Highly optimized queries for common operations (like list
rendering)
Data is often directly translated from SQL to HTML
Very complex, but efficient
Does not work for custom SharePoint development 
“Hansabank” application model
“Hansapank” application model
All the relevant data can be
processed in one place
Minimal data transfer between
components
Downside: often highly complex
and difficult to maintain
Use only performance-critical
areas
Lessons learned
Identify with the data, think about the roundtrips and stages it will go
through
Model choice is an architectural decision
Determine which model you will use early on in the design phase
Very difficult to change afterwards
90% of performance problems are designed in, not coded in
People often think of performance as something that can be optimized in code after the
fact – it doesn’t work this way
Never, ever assume you know anything
Profile early and often
Be afraid of the dark
If you don’t know how a certain code path works, chances are it will be slow and include
unexpected work
Things get worse on their own
Think about all aspects of performance
CPU, Memory, I/O, Network
Lessons learned 2
Inspect the source, become one with the code
(Linus Torvalds)
Programmer’s best textbook is source code
In open source, infinite amounts of available reading
material
In closed source, examine the behavior of your building
blocks, see how they behave in different conditions
Profile, profile, profile
Thank You. Questions?