The gremlins in my computer

I know being superstitious isnt what a programmer should be, but im a little that way when it comes to really strange bugs.
At the moment, my application suddenly stopped cycling quickly and started going with a really poor framerate… All I do is uncomment
this for loop and then all of sudden it starts going really slow.

all tiles have 0 astones so it shouldnt even be accessing the loops even though it somehow is, and the simple commented out for loop iterating
the v variable is enough to make it go slow for no reason.
I thought maybe it was because I had too much stuff in a single file, so I broke the program up to another file but it didnt make a difference, for
some reason its going slow and I have NO IDEA WHY.

As soon as I comment out the for loop it decides to go quick, and note ITS NOT RENDERING ANYTHING.


 for(i=0;i<btile[edit_tile].astones;i++)
   {
	if(btile[edit_tile].astone[i].enabled)
	{ 
     if(btile[edit_tile].astone[i].selected && fading_trim==false && fading_trim_depth==false && fading_depth==false)
     {
 // 	  eng.render(btile[edit_tile].astone[i].vs,btile[edit_tile].astone[i].v,btile[edit_tile].astone[i].ts,btile[edit_tile].astone[i].t,id,false, btile[edit_tile].astone[i].blight);     
     }
     else
     {
//	  eng.render(btile[edit_tile].astone[i].vs,btile[edit_tile].astone[i].v,btile[edit_tile].astone[i].ts,btile[edit_tile].astone[i].t,id,true, btile[edit_tile].astone[i].blight);
     }     
	}
   }

   
   int v;
   for(v=0;v<8;v++)
   {
/*	   
	switch(v)
	{
	 case 0:trans.set_trans(-2, 0, 2);break;	
	 case 1:trans.set_trans(0, 0, 2);break;	
	 case 2:trans.set_trans(2, 0, 2);break;	
	 case 3:trans.set_trans(-2, 0, 0);break;	
	 case 4:trans.set_trans(2, 0, 0);break;	
	 case 5:trans.set_trans(-2, 0, -2);break;	
	 case 6:trans.set_trans(0, 0, -2);break;	
	 case 7:trans.set_trans(2, 0, -2);break;	
	}

	for(i=0;i<btile[view_tile[v]].astones;i++)
    {
	 if(btile[view_tile[v]].astone[i].enabled)
	 { 
     // eng.render(btile[view_tile[v]].astone[i].vs,btile[view_tile[v]].astone[i].v,btile[view_tile[v]].astone[i].ts,btile[view_tile[v]].astone[i].t,trans,true, btile[view_tile[v]].astone[i].blight);
     }
     
    }
*/
   }

Its not because im using too much ram, because I checked that… anyone can help me with this really strange problem, like, can anything else you know of could slow a program down for virtually no reason?

Ive in fact mucked around with it more, and I got it working from commenting out completely safe code thats not doing any work at all just returning false and not even chaining to it and it still triggers off the slowness!!! what could be the problem?!?!?

I would print out what is in btile[edit_tile].astone[i] just to be sure it is what you think it is.

Its strange, I got it going quick again by commenting out code, then all I did was add more code that I didnt even call and it went slow again.

Maybe I should try changing editors, whats another editor like Eclipse out there? Ill try and install it… thanks if anyone can help me.

I REALLY want this program to work… Its my next big thing if I can finish it, and I feel like throwing the computer out the friggin window!

You wouldnt believe it, now ive added more code ive just commented the WHOLE thing out and now its going slow and im doing nothing.

Ive even tested multiple IDE’s now, and both have the same output, slowness - what the hell could be going wrong dammit!

Define fast.
Define slow.

50 vs. 45 frames per second?
500 vs. 3 frames per second?

Dropped from 60 to about 5.

GUESS WHAT THE HELL IT WAS!!

I had too much code in the “run” function for my applet, All I did was drop some code into a function and it restored the speed.

Have you ever heard of that before anyone?!? Thanks Riven anyway.

Well, HotSpot (the Java Just-in-Time compiler) gives up most optimizations on MASSIVE methods. Hundreds of lines.

So it doesnt even sound suprising to you, im learning lots me, gosh.

Keep in mind that the java compiler (sourcecode=>bytecode) is doing little to no optimization. Every optimization is performed at runtime. Just compare how long a C compiler can take to compile an entire project (minutes / hours) and how long it takes in Java (seconds, if that… Eclipse is continually compiling every character typed, making compilation time almost zero seconds).

Now in those few seconds the HotSpot JIT compiler is analyzing your code at runtime, it approaches (on average) 90% of the performance the best C compiler achieves.

Give that fact, it’s understandable that the HotSpot JIT tends to give up earlier on ‘too complex code’, as it would make the application stutter.

Cool.

Im just glad I didnt give up and worked out the problem, cause my little program was going great until this happened, now I can keep developing it. ;D

Despite of this more uncommon problem (most java devs have methods < 50 lines in 98% of the cases), you should make yourself familiar with a profiler. You get one for free build in, if you use Netbeans, which is more or less the same like Visual VM, that you can run standalone.