Hi,
Can you make count a field and rerun? Not sure the for loop is being unrolled in either case as the index is a long. I’ve not checked unrolling but using a long can cause the JIT to miss optimizations that it would normally apply if an int was used instead. You might want to see what JITWatch can tell you. — Kirk > On Dec 27, 2017, at 10:09 AM, Peter Veentjer <[email protected]> wrote: > > As part of an experiment, I'm working on querying large volumes of data which > is stored offheap. > > The content of each record is stored in a chunk of offheap memory. So instead > of having an array of object references, it is an array of records (no > pointer chasing). > > My confusion is about some code I'm generating based on the query content. > There are 2 flavors; one flavor where I'm printing if I found something and > the other flavor increments a local long variable and print this at the end > of the loop. > > The strange thing is that the first one (printing when the correct entry is > found), is 15x faster than the one where I'm increasing the local counter. > > So this is the first: > > import java.util.*; > public class FullTableScan_e872b2bd8f274cc18b37ac2a0e3df2ed extends > com.hazelcast.simplemap.impl.FullTableScan{ > public void run(){ > long offset=slabPointer; > for(long l=0;l<recordIndex;l++){ > if((unsafe.getInt(offset+12)==10000) && > (unsafe.getBoolean(null,offset+16)==true)){ > System.out.println("found"); > } > offset+=recordDataSize; > } > > } > public void init(Map<String, Object> binding){ > } > } > > > And this is the second: > import java.util.*; > public class FullTableScan_e872b2bd8f274cc18b37ac2a0e3df2ed extends > com.hazelcast.simplemap.impl.FullTableScan{ > public void run(){ > long offset=slabPointer; > long count = 0; > for(long l=0;l<recordIndex;l++){ > if((unsafe.getInt(offset+12)==10000) && > (unsafe.getBoolean(null,offset+16)==true)){ > count++; > } > offset+=recordDataSize; > } > System.out.println("count:"+count); > } > public void init(Map<String, Object> binding){ > } > } > > What could be the reason of this huge performance difference? It isn't a > warmup problem since it was running for 5 minutes. Could there be some data > dependency with the second loop that prevents the loop to be unrolled? I > should analyze the assembler; perhaps this will shed some light on the > situation. > > -- > You received this message because you are subscribed to the Google Groups > "mechanical-sympathy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
