Is there any way I can access heap memory faster?

**FunkyTecknician** · July 27th, 2011, 02:03 AM

Hi there. I've written some code that frequently accesses a dynamically created object during a loop structure. My problem is that I've noticed that accessing fields within
my object is significantly slower than accessing stack memory.

For example, if I benchmark the duration of the following code:

float x = 0.0f;
 
for (int i = 0; i < 1000000; i++)
x = 0.5f * 0.5f;

It is way quicker than this (assume 'val' is a float defined within the object 'x'):

FloatObject x = new FloatObject();
 
for (int i = 0; i < 1000000; i++)
x.val = 0.5f * 0.5f;

I won't deny for a moment that I'm a noob with Java. I believe the latter phenomenon is due to the JIT "finding" the object x in memory every time it is called upon, or, perhaps
something to do with the garbage collector.

My question is: Is there any way to speed up access of heap data? I realize that the stack will always be faster, but I'd like to know if there's a compiler argument
that might allow faster access to heap data.

Thanks for your time.

**copeg** · July 27th, 2011, 08:37 AM

What was the result of your benchmark? I run that code and the difference is 1-2 milliseconds, the total duration less than 5 miliiseconds. Crank that loop up even further with similar results. I won't argue that there might be a difference between the two, however in the runtime of a program that difference would be virtually unobservable to a user. If you are having delay issues in a program, I highly recommend profiling the code to see where that delay lies - because more often than not it will be something you did not expect (so why waste time trying to fix something that isn't broken).

**FunkyTecknician** · July 27th, 2011, 09:05 AM

You're right.

My first micro benchmark used higher iteration values, which I can't recall specifically. However, the time difference was significant, something like 0.004 seconds for the float primitive versus 0.45 seconds for the float object. However, curiously, when I added a few lines to display what the final value was of each "test subject" value (e.g., the float 'x') using println, the benchmarks changed. It seems as though the compiler is aware a variable isn't accessed and thus doesn't even bother calculating it, causing the unpredictable benchmarks. Suffice it to say, both the primitive and the object had similar durations when I made the latter modification.

Java tends to defy reason to me. Why is it that the following returns 0.089 seconds:

for ( int i = 0; i < 2000000000; i++ )
	ObjectFloat.x = 0.5f * 0.5f;

...And this takes exactly the same amount of time to calculate?:

for ( int i = 0; i < 2000000000; i++ )
{
	ObjectFloat.x = 0.5f * 0.5f;
	ObjectFloat.y = 0.5f * 0.5f;
	ObjectFloat.z = 0.5f * 0.5f;
}

Shouldn't the second example take 3 times longer?

Thanks.

**Norm** · July 27th, 2011, 10:27 AM

Why 3 times? What proportion of the code is the assignments, what producing the product and what proportion is the looping?

**copeg** · July 27th, 2011, 12:01 PM

I think your splitting hairs here...but if you wish to try and figure out what truly is going on, you might consider learning a bit about bytecode and how the JVM works. You can view the bytecode of a compiled class using the javap tool. For instance, in your very first example, the value x is never needed to be pushed onto the stack within the loop (its value is simply set), relative to the second example in your first post in which the object must first be pushed onto the stack and then its value set. You can sit around and fine tune these operations to try and speed things up, but like I said you may be trying to optimize something that will provide you with no noticeable gain in performance.

**helloworld922** · July 27th, 2011, 10:45 PM

Micro-profiling java code (or any "interpreted" language) is not the same as profiling statically compiled code (something like C++). The JVM is dynamically managing the memory, as well as JIT'ing the Java bytecode into native code. To create a good microprofiler, you need to execute the code multiple times in one run, then take the average running time (ignore the fastest/slowest times). Usually I like including a "spin up" and "spin down" section which will perform the computation, but won't get timed. The JVM is also very good at identify areas it can optimize away without affecting the actual workings of the code. Additionally, the amount of time it takes should be somewhat long compared to the timer resolution (roughly 1-10 ms) to reduce the effects of fluctuations due to the the operations of the JVM/OS.

Garbage collectors in this kind of situation actually help to improve performance time because the object doesn't have to be reclaimed right away, rather could be reclaimed after the program terminates.

In any case, the time difference between the two is negligible. There isn't any way "software wise" to be able to access the heap any faster.

final int COUNT = 0x40000000;
		final int TIMES = 10;
		{
			// spin-up
			float x = 0.5f;
			for (int i = 0; i < COUNT; i++)
			{
				x *= 0.5f;
			}
 
			long total_time = 0;
			long start_time;
			for (int j = 0; j < TIMES; ++j)
			{
				// run the test
				start_time = System.currentTimeMillis();
				for (int i = 0; i < COUNT; ++i)
				{
					x *= 0.5f;
				}
				total_time += System.currentTimeMillis() - start_time;
			}
			// spin-down
			for (int i = 0; i < COUNT; i++)
			{
				x *= 0.5f;
			}
			total_time /= TIMES;
			System.out.println("allocated on the stack average time: " + total_time);
		}
		{
			// spin-up
			float x[] = new float[1];
			x[0] = 0.5f;
			for (int i = 0; i < COUNT; i++)
			{
				x[0] *= 0.5f;
			}
 
			long total_time = 0;
			long start_time;
			for (int j = 0; j < TIMES; ++j)
			{
				// run the test
				start_time = System.currentTimeMillis();
				for (int i = 0; i < COUNT; ++i)
				{
					x[0] *= 0.5f;
				}
				total_time += System.currentTimeMillis() - start_time;
			}
			// spin-down
			for (int i = 0; i < COUNT; i++)
			{
				x[0] *= 0.5f;
			}
			total_time /= TIMES;
			System.out.println("allocated on the heap average time: " + total_time);
		}

**FunkyTecknician** · July 28th, 2011, 02:55 AM

Thank you very much for your attentive replies.

Why 3 times? What proportion of the code is the assignments, what producing the product and what proportion is the looping?

I assumed 3 times because there are 3 times as many instructions within the loop. If you look closely, each field is different (x, y and z) in each assignment, so as to "throw off" the JVM.

...You can view the bytecode of a compiled class using the javap tool...

Nice! I didn't know something like this existed. I approach coding like how it was done in the DOS days, I like to pay attention to cycles. I realize that Java is more involved than the compile-time nature of old C and C++, so javap might help me resolve that to some extent.

allocated on the stack average time: 1562
allocated on the heap average time: 1562

Thanks for the code and explanation, helloworld922! After running your code, I got the latter results. They're exactly the same, which is a relief. I was worried some bottlenecks in a project I'm working on were due to slow heap access, but now I realize my error was the simplicity of my micro benchmarks and the complexity of the JVM. It seems I'm still too accustomed to C++. Your use of the "spin up/down" phases seem like a clever way of priming the JVM.

**dlorde** · July 28th, 2011, 07:09 PM

There's a reason all the programming gurus feel so strongly about optimization...

Premature optimization is the root of all evil in programming - C.A.R. Hoare

Rules of Optimization:
Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet. - M. A. Jackson

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. - D. Knuth

More bugs have been introduced into programs through premature optimization than any other cause, including pure stupidity.- W. Wulf

Simplicity and flexibility will trump optimization and power in a world where connectivity is the key. - A. Bosworth

etc.

**FunkyTecknician** · July 29th, 2011, 11:51 PM

Very good advice dlorde, thanks!

Thread: Is there any way I can access heap memory faster?

LinkBack

Thread Tools

Display

Is there any way I can access heap memory faster?

Related threads:

Re: Is there any way I can access heap memory faster?

The Following User Says Thank You to copeg For This Useful Post:

Re: Is there any way I can access heap memory faster?

Re: Is there any way I can access heap memory faster?

Re: Is there any way I can access heap memory faster?

The Following User Says Thank You to copeg For This Useful Post:

Re: Is there any way I can access heap memory faster?

The Following 2 Users Say Thank You to helloworld922 For This Useful Post:

Re: Is there any way I can access heap memory faster?

Re: Is there any way I can access heap memory faster?

The Following User Says Thank You to dlorde For This Useful Post:

Re: Is there any way I can access heap memory faster?

Similar Threads

[SOLVED] Faster Run Time - Scanner(file) and Arrays

Memory Handling -de allocate memory in Java

Out of Memory Error

Out of memory - Java heap space

Default Access (package access) confusion