Let's do this.

[f.l.x]

ok more strange things (at least for me)

several line statements like:

1   2   3

double _jy = (getHeight() / 2              - ((getHeight() / 2 - (FIELD_Y + FIELD_H)) * df))              / e.getY() - df;

seems to add a couple of bytes to what this would produce:

1	double _jy = (getHeight() / 2 - ((getHeight() / 2 - (FIELD_Y + FIELD_H)) * df)) / e.getY() - df;

All these are new things for me, i'm learning a lot with this contest, but i don't know what are true or what are just the affairs of the pixie that lives inside my pc.

[Morre]

I assume there's no difference after compiling between the different casting types for simple data types? (float)1 and 1F, for example? Just curious :>

[Anon666]

hmmm

i have made some test on that  long constants optimizing

Mi early state game with this:

df = (int)((getWidth() / 2) / Math.tan(Math.PI / 4));

jared  3918b

with this
df = (int)((getWidth() / 2) / (float)Math.tan(Math.PI / 4));

3920b

but, it's not significative, i have been noticing something very strange:

before doing nothing to the code: 3920b
after adding a new blank line 3916b

 

the actual size of the bytecode can be affected simply by recompiling??!!

The bit you want to be casting in that expression is the ((float)Math.PI)/2.

When performing micro-optimisations I don't find it useful comparing the compressed jar size, as you cannot feasably measure the results of your change.

Simply try and reduce your compiled class size by as much as possible, (so the information being stored has reduced - atleast giving the potencial for the jar to get smaller)
while also considering any potencial reduction in the size of the symbol set used in the file. (to aid the compression algorithm)

Games published by our own members! Check 'em out!

[Anon666]

ok more strange things (at least for me)

several line statements like:

1   2   3

double _jy = (getHeight() / 2              - ((getHeight() / 2 - (FIELD_Y + FIELD_H)) * df))              / e.getY() - df;

seems to add a couple of bytes to what this would produce:

1	double _jy = (getHeight() / 2 - ((getHeight() / 2 - (FIELD_Y + FIELD_H)) * df)) / e.getY() - df;

All these are new things for me, i'm learning a lot with this contest, but i don't know what are true or what are just the affairs of the pixie that lives inside my pc.

The only difference that could have on the resultant class file size, is that the debug information would be larger.
You should be compiling with debug off. (though passing the classes through any kind of obfuscator would also remove this information)

With debug off, white space has *zero* impact of the resultant binary size.

[f.l.x]

thanks that clarifies it a lot

[Anon666]

I assume there's no difference after compiling between the different casting types for simple data types? (float)1 and 1F, for example? Just curious :>

Compiling with javac, no, both of those expressions would be resolved to the same bytecode.

However from a bytecode perspective they are different.

Example 1:

(float)1 occupies 2bytes :-

1   2

iconst_1 //push the integer constant 1 onto the stack i2f            //converts the integer on the top of the stack to a float

1F occupies just 1byte :-

1	fconst_1 // push the float constant 1.0f onto the stack.

Javac would always evaluate both expressions to the second bytecode sequence - which is optimal.

However - if the value '1' was replaced with the value '5', things become a little different.

Example 2:

(float)5 still occupies 2 bytes :-

1   2

iconst_5 // push the constant 5 onto the stack i2f            // cast it to a float.

however, 5F occupies a total of 4+2 bytes! :-

1   2   3   4

constants pool Entry: [1] = 5.0f (4bytes) ldc 1// load constant 1 onto the stack

In this instance, Javac would again generate bytecode that matched the second case.
However in this case, it is clearly not size-optimal.

The reason for the difference, is the bytecode instruction set contains 6 single bytecode instructions for pushing the integer constants (-1 through to +5) onto the stack,
where-as it has only 3  single bytecode instructions for pushing float constants (0 through to +2) onto the stack.

Incidentally, this is a good site for a clear overview of the instruction set:

http://homepages.inf.ed.ac.uk/kwxm/JVM/codeByNo.html