Re: Getter performance
On 10/15/2011 5:03 PM, A??ris wrote:
I work on an application where performances are important.
To optimize it, I thought a direct access to a variable (foo.bar) would
be more efficient than a getter call (foo.getBar()).
I thought by avoiding the call to a method and all that goes with it
(context switching, stacking, return value???), I can save time, but this
code sample prove the contrary :
http://pastebin.com/bP1nqxce
Direct variable access : 1041 ms
Getter call : 556 ms
The difference is even more important if I don't modify the variable
value (lines 29 and 36 commented) :
Direct variable access : 95 ms
Getter call : 4 ms
How can we explain this not obvious huge difference ( 50 and 95% ) ?
Insufficiently precise measurement. You are trying to tell
whether two nickels are heavier than four pennies by piling each
stack of coins in turn atop a bulldozer and weighing the bulldozer.
If you want to measure tiny effects, seek a measurement framework
that doesn't involve huge effects.
Fundamentally, though, you're going about the larger task in
the wrong way: You are simply guessing that the speed of access to
a variable is important to the performance of your application. Do
you have even the slightest shred of evidence that this is so? Or
are you trying to improve your car's fuel economy by scraping off
all the paint to reduce the vehicle weight?
1: Decide what performance criteria the application must satisfy.
Make this quantifiable: "Throughput of at least X doodads per eyeblink"
or "95% of responses in no more than Y milliquivers," not undecidable
like "As fast as possible."
2: (Optional) Make back-of-the-envelope calculations about data
rates, data set sizes, and so on, just to estimate the resources
that will be required. Is the load within reach of a laptop, or do
you need a clustered network of supercomputers? Can you handle the
traffic with WiFi, or do you need sixteen 10Gb/s fibers in parallel?
3: Write the application, as cleanly and simply as you can in
light of [1] and [2]. During this stage, bear in mind that even the
most expert of programmers is usually surprised about where his code
spends the majority of its time (this is not opinion; it's been found
over and over again in actual experiment). In other words, favor
"clean and simple" over "clever and reputedly fast."
4: Measure the performance, and compare to the thresholds of [1].
If you satisfy [1], stop!
5: (Only if [1] isn't satisfied) Apply profilers, debuggers, and
other tools to discover which parts of the program are too slow. Apply
your efforts to speeding up those parts only; pay no attention to the
others. Then return to [4]. In very rare cases (usually when [2] was
skipped or when some external agency forces a change in [1]), return
to [3] and start over.
Do not begin by trying to micro-optimize; that way lies madness.
Trust me; I know: Been there, done that, bear the scars.
--
Eric Sosman
esosman@ieee-dot-org.invalid