Bugzilla

(In reply to Jonas Jenwald [:Snuffleupagus] from comment #3)
> (In reply to Calixte Denizet (:calixte) from comment #2)
> > There wrong "C" & "B" images above the horizontal line are something else (maybe a cache issue somewhere).
> 
> Yes, something seems to go wrong when caching in the `Parser.makeInlineImage` method. Unfortunately I don't immediately understand what though.

The culprit for this part of the bug is the `computeAdler32` function, since it appears to generate hash collision for some of the inline image data in question. While it's trivial to replace it with something better, e.g. our existing `MurmurHash3_64` class, that'd affect performance quite badly in already slow cases (for example issue 2618).

My *theory* is that the `computeAdler32` function doesn't cope well with very short data, which is the case here, so we could perhaps use `computeAdler32` for sufficiently "short" inline images. Although it's not clear to me where the cut-off point should be, to avoid performance regressions elsewhere?

(In reply to Jonas Jenwald [:Snuffleupagus] from comment #3)
> (In reply to Calixte Denizet (:calixte) from comment #2)
> > There wrong "C" & "B" images above the horizontal line are something else (maybe a cache issue somewhere).
> 
> Yes, something seems to go wrong when caching in the `Parser.makeInlineImage` method. Unfortunately I don't immediately understand what though.

The culprit for this part of the bug is the `computeAdler32` function, since it appears to generate hash collision for some of the inline image data in question. While it's trivial to replace it with something better, e.g. our existing `MurmurHash3_64` class, that'd affect performance quite badly in already slow cases (for example issue 2618).

My *theory* is that the `computeAdler32` function doesn't cope well with very short data, which is the case here, so we could perhaps use `MurmurHash3_64` for sufficiently "short" inline images. Although it's not clear to me where the cut-off point should be, to avoid performance regressions elsewhere?

(In reply to Jonas Jenwald [:Snuffleupagus] from comment #3)
> (In reply to Calixte Denizet (:calixte) from comment #2)
> > There wrong "C" & "B" images above the horizontal line are something else (maybe a cache issue somewhere).
> 
> Yes, something seems to go wrong when caching in the `Parser.makeInlineImage` method. Unfortunately I don't immediately understand what though.

The culprit for this part of the bug is the `computeAdler32` function, since it appears to generate hash collisions for some of the inline image data in question. While it's trivial to replace it with something better, e.g. our existing `MurmurHash3_64` class, that'd affect performance quite badly in already slow cases (for example issue 2618).

My *theory* is that the `computeAdler32` function doesn't cope well with very short data, which is the case here, so we could perhaps use `MurmurHash3_64` for sufficiently "short" inline images. Although it's not clear to me where the cut-off point should be, to avoid performance regressions elsewhere?