Re: [Fenfire-dev] Proposed change to VobCoorder.RenderInfo

[Benja Fallenstein]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matti Katila wrote:
| Just one thing. It may use more memory and efficiency resources
because of
| the change?

Nope. We're doing slightly less work than before: before, we'd do a
method call (getExtRect(Rectangle)) that would read some instance
variables (of the RenderInfo) and then change some instance variables
(of the Rectangle passed to getExtRect()). After getExtRect() returned,
we would then read the instance variables from that Rectangle.

Now, we replace all of the above by only once reading the instance
variables of the RenderInfo. Less work.

However, even if it was more work, remember rule #1 of writing efficient
programs: Profile, find the bottlenecks, and fix them. Don't "optimize"
prematurely (i.e., before you know what the bottleneck is). Let's say
that you know that the following inner loop is too slow:

~    void printEverySecondChar(char[] chars) {
~        for(int i=0; i<chars.length; i+=2) {
~            System.out.print(chars[i];
~        }
~    }

Now you might try to avoid some instance variable accesses and loop
bound checks by re-writing the loop like this:

~    void printEverySecondChar(char[] chars) {
~        int i, len = chars.length;
~        for(i=0; i<chars.length; i+=4) {
~            System.out.print(chars[i]);
~            System.out.print(chars[i+2]);
~        }
~        if(i-2 < chars.length) System.out.print(chars[i-2]);
~    }

However, this clever re-write will not help, the loop will practically
be as slow as before -- because the real problem is that
System.out.print() is slow, *very* slow compared to a single loop bound
check. A much more effective re-write would probably be:

~    void printEverySecondChar(char[] chars) {
~        char[] n = new char[chars.length/2];
~        for(i=0; i<n.length; i++) n[i] = chars[2*i];
~        System.out.print(n);
~    }

(-- only problem being creating one more object for the garbage
collector; if *that* is a problem, things get interesting, but that's
off-the-point here.)

Basically, experience shows that with optimization, it's always like
above: there is one place where most time is spent, and "optimizing"
elsewhere does not bring real benefits. Therefore, the rule -- don't
optimize until you know where the problem is.

In the case we were talking about, the render loop, accessing a few
instance variables comes at essentially no cost compared to the time the
AWT methods take for the actual rendering. We have had problems before
when a vob's render method called a time-consuming loop somewhere else
(e.g. in ScaleableFont), but accessing one more instance variable or
calling one more getXYZ() method shouldn't make a difference in a
Vob.render() method.

Cheers,
- - Benja
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFA6+GYUvR5J6wSKPMRAmaAAJ9pqsfPjHFJRUAWazyVSRlJzK17UgCfWt1M
PAJrWlLtHMMcjbRBAzqI7KE=
=CCcN
-----END PGP SIGNATURE-----