Improve performance of LongByteMappingStore

[dlogothetis]

Part of the overhead comes from using an atomicinteger that's written to for every entry addition. I don't see any particular value in this keeping this counter, which incurs high overhead is it is accessed on every entry. There are better ways to update it as values are added, if we think this is useful, we can add it then.

Modified also the getByteTarget method to do one less hashmap access as per the comment by @spupyrev .

Tests

• mvn -Phadoop_facebook clean install
• mvn -Phadoop_2 clean install
• Ran jobs that read a mapping, this reduces the time to load mapping by up to 50%.

https://issues.apache.org/jira/browse/GIRAPH-1210

[spupyrev]

Can we also modify getByteTarget method to the following:
public byte getByteTarget(LongWritable vertexId) { long key = vertexId.get() >>> lowerOrder; byte[] bs = idToBytes.get(key); if (bs == null) { return -1; } int suffix = (int) (vertexId.get() & lowerBitMask); return bs[suffix]; }