Skip to content

Conversation

@franz1981
Copy link
Contributor

The search algorithm chosen is Knuth-Morris-Pratt and could make
use of an additional jump table with certain Symbols

…uffer

The search algorithm chosen is Knuth-Morris-Pratt and could make
use of an additional jump table with certain Symbols
@franz1981
Copy link
Contributor Author

franz1981 commented Feb 10, 2020

Some benchmark results are on netty/netty#9955
I've yet to decide if it makes sense to provide our own benchmarks, given that the reason of this "feature" is for some specific use cases (see apache/artemis#2975).

@franz1981
Copy link
Contributor Author

I see that I'm not accounting for remaining space to search in to be less then the needle to search for :)

Copy link
Member

@gemmellr gemmellr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dont think it really makes sense to add this to the Symbol object itself, since it doesn't actually identify an encoded Symbol in the provided buffer, but rather a sequence of bytes in the buffer that matches its ascii content, but which could be from [part of] absolutely any type or value. Essentially its a general search of the buffer, which seems more suited to being outside the Symbol class if anywhere to me.

int j = 0;
final int[] jumpTable = racyGerOrCreateJumpTable();
final byte[] needle = _underlyingBytes;
final long length = to - from;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given the other checking above, should it perhaps also validate that to <= from?

throw new IllegalArgumentException("range indexes cannot be negative!");
}
int j = 0;
final int[] jumpTable = racyGerOrCreateJumpTable();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure what Ger is ;)

final int[] jumpTable = racyGerOrCreateJumpTable();
final byte[] needle = _underlyingBytes;
final long length = to - from;
final ReadableBuffer haystack = buffer;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason not to just declare the method arg with the desired name + final?

final long length = to - from;
final ReadableBuffer haystack = buffer;
final int needleLength = needle.length;
for (int i = 0; i < length; i++)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would initialising i to 'from' rather than 0 simplify things? (Plus other adjustments accordingly, e.g rename i to index, to rather than length)

@franz1981
Copy link
Contributor Author

Hi @gemmellr I can close this and sorry to have made you to review this: I've included this general purpose search method directly on AMQ code base, but still, would be useful (maybe in a new codec) a method to perform a "real" search for a specific property key in some section of AMQP, instead of a greedy approach like this.

@franz1981 franz1981 closed this Mar 27, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants