There are no large string values involved, I had a look with wget for testing to see what OH is actually publishing and those were all “normal”/“short” messages, nothing that looked different from what the OH Demo instance is sending. I will wait to see if this improved the situation now, if not I will do additional debugging by hooking functions and adding debug output, that’s a little harder to set up but I can certainly do that in case these optimizations were not enough/didn’t solve the problem. Then I should be able to see what messages actually arrive and when they arrive, I am pretty sure that it’s fixed now though.
I don’t see any reason why it shouldn’t work: You could still override the generated class code, or provide an alternative implementation for example by adding a cachedHashCode()
method which then does this:
if(cachedHash == null)
cachedHash = hashcode();
return cachedHash;
And then override the equals to something like this (or add a cachedEquals and use that one):
if(otherItem == null)
return false;
if (getClass() != otherItem.getClass())
return false;
return cachedHashCode() == otherItem.cachedHashCode();
Don’t forget to set cachedHash = null in every setter-method to invalidate the cached value. I intentionally left out the “this == other”-check as that seems to be something that doesn’t happen very often and the cachedHashCode() would be equal then aswell, so it would still work correctly, just slower if the cachedHashCode isn’t generated yet (but an additional comparison would be gone, so if that’s indeed almost never happening it sounds like a fair deal to me, but that’s just a personal opinion from someone who doesn’t know the code at all).
I am seeing this on a wall-mounted Xiaomi MiPad 2 tablet which is my main device. It has a 4 core Intel CPU and 2GB of RAM (about 500MB are usually free).