peter-lawrey / HugeCollections-OLD

Huge Collections for Java using efficient off heap storage
273 stars 51 forks source link

too many Segment.getKey() invocations #45

Open mesutcank opened 9 years ago

mesutcank commented 9 years ago

I attached a profiler to my application and I saw that call tree:

image

I invoked Map.get() 8379 times and also net.openhft.collections.HugeHashMap$Segment.get is invoked same amount but Segment.getKey() is invoked 9.903.392 times.

Why getKey() invocation count is more about 1000 times than Map.get() count?

My get code:


for (Long key : cache.keySet()) {
    sr = cache.get(key);

    if (sr != null && sr.isDirty() && sr.isInDb()) {
        ++updateCount;

        sr.setClean();
        try {
            cache.put(key, sr);
        } catch (Exception e) {
        // discard
        }
    }
}
RobAustin commented 9 years ago

In most cases you can replace your use of HugeHashMap with ChronicleMap, could you try using ChronicleMap.

We are focusing most of our new development and support effort on ChronicleMap.

On 27 Oct 2014, at 10:49, Mesutcan Kurt notifications@github.com wrote:

I attached a profiler to my application and I saw that call tree:

https://cloud.githubusercontent.com/assets/439170/4789483/9a28a160-5dc5-11e4-9c8f-efffd151d9ba.png I invoked Map.get() 8379 times and also net.openhft.collections.HugeHashMap$Segment.get is invoked same amount but Segment.getKey() is invoked 9.903.392 times.

Why getKey() invocation count is more about 1000 times than Map.get() count?

My get code:

for (Long key : cache.keySet()) { sr = cache.get(key);

if (sr != null && sr.isDirty() && sr.isInDb()) {
    ++updateCount;

    sr.setClean();
    try {
        cache.put(key, sr);
    } catch (Exception e) {
    // discard
    }
}

}

— Reply to this email directly or view it on GitHub https://github.com/OpenHFT/HugeCollections/issues/45.

peter-lawrey commented 9 years ago

If you want to iterate over the entries of any Map (not just ours) the most efficient means is to use entrySet()

e.g.

for (Map.Entry<Long, SR> entry: cache.entrySet()) {

as you can see there is no need to lookup the entry via get()

BTW We have a means of efficiently persisting a Map to a JDBC connection, perhaps you try this means of "replication"

On 27 October 2014 10:49, Mesutcan Kurt notifications@github.com wrote:

I attached a profiler to my application and I saw that call tree:

[image: image] https://cloud.githubusercontent.com/assets/439170/4789483/9a28a160-5dc5-11e4-9c8f-efffd151d9ba.png

I invoked Map.get() 8379 times and also net.openhft.collections.HugeHashMap$Segment.get is invoked same amount but Segment.getKey() is invoked 9.903.392 times.

Why getKey() invocation count is more about 1000 times than Map.get() count?

My get code:

for (Long key : cache.keySet()) { sr = cache.get(key);

if (sr != null && sr.isDirty() && sr.isInDb()) {
    ++updateCount;

    sr.setClean();
    try {
        cache.put(key, sr);
    } catch (Exception e) {
    // discard
    }
}}

— Reply to this email directly or view it on GitHub https://github.com/OpenHFT/HugeCollections/issues/45.

peter-lawrey commented 9 years ago

BTW This could happen if you HugeHashMap is very full. (i.e. it is heavily loaded compared to it's capacity) When this happens, you might find a very large number of lookups are performed to find each key.

On 27 October 2014 10:49, Mesutcan Kurt notifications@github.com wrote:

I attached a profiler to my application and I saw that call tree:

[image: image] https://cloud.githubusercontent.com/assets/439170/4789483/9a28a160-5dc5-11e4-9c8f-efffd151d9ba.png

I invoked Map.get() 8379 times and also net.openhft.collections.HugeHashMap$Segment.get is invoked same amount but Segment.getKey() is invoked 9.903.392 times.

Why getKey() invocation count is more about 1000 times than Map.get() count?

My get code:

for (Long key : cache.keySet()) { sr = cache.get(key);

if (sr != null && sr.isDirty() && sr.isInDb()) {
    ++updateCount;

    sr.setClean();
    try {
        cache.put(key, sr);
    } catch (Exception e) {
    // discard
    }
}}

— Reply to this email directly or view it on GitHub https://github.com/OpenHFT/HugeCollections/issues/45.