You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by GitBox <gi...@apache.org> on 2021/11/22 08:43:38 UTC
[GitHub] [lucene] hendrikmuhs opened a new pull request #460: LUCENE-10247 - reduce size of FSTs by relative coding
hendrikmuhs opened a new pull request #460:
URL: https://github.com/apache/lucene/pull/460
See: https://issues.apache.org/jira/browse/LUCENE-10247
----------------------
FST's use various tricks to reduce size. One more trick that can be added is using relative coding for the target pointers that connect nodes.
Currently if a node has a target and it's not optimized using the `next` flag, it writes a VLong which contains the address of the child. This is an absolute address. A relative address can be shorter, relative address means taking the address of the node and expressing the result of child node as diff between the parent and the child. E.g. if the child is 10099 and the parent 10000, an absolute pointer requires 2 bytes, but the relative pointer (10099 - 10000) requires only 1 byte. Of course that's not always true, the absolute pointer could be smaller. Therefore the idea is to switch between the two, dependent on what's smaller.
----------------------
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org
[GitHub] [lucene] dweiss commented on a change in pull request #460: LUCENE-10247 - reduce size of FSTs by relative coding
Posted by GitBox <gi...@apache.org>.
dweiss commented on a change in pull request #460:
URL: https://github.com/apache/lucene/pull/460#discussion_r754558907
##########
File path: lucene/core/src/java/org/apache/lucene/util/fst/Util.java
##########
@@ -878,11 +878,20 @@ public static BytesRef toBytesRef(IntsRef input, BytesRefBuilder scratch) {
} else if (arc.isLast()) {
return null;
} else {
- fst.readNextRealArc(arc, in);
+ fst.readNextRealArc(arc, in, follow.target());
}
}
}
+ public static int calculateVLongLength(long i) {
Review comment:
This can be computed directly (without the loop) from the number of leading zeros (Long.numberOfLeadingZeros)?
##########
File path: lucene/codecs/src/java/org/apache/lucene/codecs/memory/FSTTermsReader.java
##########
@@ -646,7 +646,7 @@ Frame loadNextFrame(Frame top, Frame frame) throws IOException {
return null;
}
while (!frame.fstArc.isLast()) {
- frame.fstArc = fst.readNextRealArc(frame.fstArc, fstReader);
+ frame.fstArc = fst.readNextRealArc(frame.fstArc, fstReader, top.fstArc.target());
Review comment:
Yeah... this extra parameter is only adding confusion to those methods - I never liked them too much, it'd be great to have some kind of abstraction for iterating over node's arcs (but it'd slow down things too). Eh.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org
[GitHub] [lucene] hendrikmuhs commented on a change in pull request #460: LUCENE-10247 - reduce size of FSTs by relative coding
Posted by GitBox <gi...@apache.org>.
hendrikmuhs commented on a change in pull request #460:
URL: https://github.com/apache/lucene/pull/460#discussion_r762011132
##########
File path: lucene/core/src/java/org/apache/lucene/util/fst/FST.java
##########
@@ -1000,6 +1027,98 @@ private void writePresenceBits(
assert bytePos - dest == numPresenceBytes;
}
+ private long estimateNodeAddress(
Review comment:
Nevertheless I agree to you concern regarding code maintainability. This heuristic is in parts a copy of the logic later on.
I will try to make improvements, maybe parts can re-used. Apart from that unit tests should be added, for the parts I can't de-dup, these tests can assert the correctness if one part is changed without adapting the other.
##########
File path: lucene/core/src/java/org/apache/lucene/util/fst/FST.java
##########
@@ -1000,6 +1027,98 @@ private void writePresenceBits(
assert bytePos - dest == numPresenceBytes;
}
+ private long estimateNodeAddress(
Review comment:
Nevertheless I agree to your concern regarding code maintainability. This heuristic is in parts a copy of the logic later on.
I will try to make improvements, maybe parts can re-used. Apart from that unit tests should be added, for the parts I can't de-dup, these tests can assert the correctness if one part is changed without adapting the other.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org
[GitHub] [lucene] hendrikmuhs commented on a change in pull request #460: LUCENE-10247 - reduce size of FSTs by relative coding
Posted by GitBox <gi...@apache.org>.
hendrikmuhs commented on a change in pull request #460:
URL: https://github.com/apache/lucene/pull/460#discussion_r761990896
##########
File path: lucene/core/src/java/org/apache/lucene/util/fst/FST.java
##########
@@ -720,9 +745,9 @@ long addNode(FSTCompiler<T> fstCompiler, FSTCompiler.UnCompiledNode<T> nodeIn)
}
if (targetHasArcs && (flags & BIT_TARGET_NEXT) == 0) {
- assert target.node > 0;
+ assert targetNode > 0;
Review comment:
> also - if we were able to encode negative offsets we could always apply this variable encoding
A negative offset would mean you target a node that has not been written yet. That's not possible by design. In addition it is not necessary, the way the fst is constructed is from the leafs to the root. A parent always has a higher offset than its child. Therefore negative offsets never happen.
Absolute vs. relative coding: I wasn't able to use relative addresses all times, if "fixed length arcs" are used I switch this optimization off completely. To always use relative coding I must replace all absolute addresses. I am not sure this is even possible.
When 1st experimenting with this technique years ago, I did some measurements and calculations. In smaller fst's absolute coding is sufficient, we have small addresses anyway. The larger the fst gets the more interesting relative coding becomes. If the fst is highly compressible the absolute address was often smaller than the relative ones. E.g. leafs usually compress like that. For larger fst's and fst's that do not compress well (because of values) relative coding works nicely, because the construction yields good locality.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org
[GitHub] [lucene] hendrikmuhs commented on a change in pull request #460: LUCENE-10247 - reduce size of FSTs by relative coding
Posted by GitBox <gi...@apache.org>.
hendrikmuhs commented on a change in pull request #460:
URL: https://github.com/apache/lucene/pull/460#discussion_r754601969
##########
File path: lucene/core/src/java/org/apache/lucene/util/fst/FST.java
##########
@@ -1000,6 +1027,98 @@ private void writePresenceBits(
assert bytePos - dest == numPresenceBytes;
}
+ private long estimateNodeAddress(
Review comment:
That's the trickiest part of the whole idea. I need to know [`thisNodeAddress`](https://github.com/apache/lucene/blob/main/lucene/core/src/java/org/apache/lucene/util/fst/FST.java#L779) before writing the state. But because everything uses variable length encodings, is based on flags, might write extra fields, etc. this is hard. I considered using the position of the arc, but, the compiler reverses the bytes it wrote (L780).
So what I ended up with is pre-calculating the node address ("estimate" is therefore wrong, feel free to suggest a better name, it must be exact (or return `0`, see below), so rather "preCalculateNodeAddress").
Good to know: the heuristic is allowed to fail, in which case it returns `0` and relative coding isn't used.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org
[GitHub] [lucene] hendrikmuhs commented on a change in pull request #460: LUCENE-10247 - reduce size of FSTs by relative coding
Posted by GitBox <gi...@apache.org>.
hendrikmuhs commented on a change in pull request #460:
URL: https://github.com/apache/lucene/pull/460#discussion_r762005851
##########
File path: lucene/core/src/java/org/apache/lucene/util/fst/FST.java
##########
@@ -1000,6 +1027,98 @@ private void writePresenceBits(
assert bytePos - dest == numPresenceBytes;
}
+ private long estimateNodeAddress(
Review comment:
I agree that one pass would be easier. What makes it complicated is the variable length encodings. In order to patch up a cell you still need to reserve the right number of cells to write into. If you reserved 1 byte but later realize you need 2 you have a problem. A buffer where you can insert a cell might help, but than the whole calculation falls apart again, because the cell that you patched a step ago might need another patch and might overflow. If you look at the implementation below, this is what `tolerance` is about:
I have an estimate that says, I need to store `125`, that's `1` byte, but if it the real value will be `128` I need `2` bytes, that means my `tolerance` is `2`. When the address slides I am still fine as long as it only goes up by maximum `2`. If above `2`, I stretched my budget. The algorithm returns `0` in this case, which means it falls back to absolute coding. In the end it is a heuristic which might fail, we could do 3rd pass to catch a couple more cases, but the added benefit is probably so small that it isn't worth the extra loop (I can test this later, right now it sounds premature).
^ fits with your question regarding always using relative offsets. It would be quite hard to implement. The extra bit is for free at the moment, because the flag has a fixed size. It might be a problem if you already have other uses of flags in mind and want to reserve it.
##########
File path: lucene/core/src/java/org/apache/lucene/util/fst/FST.java
##########
@@ -720,9 +745,9 @@ long addNode(FSTCompiler<T> fstCompiler, FSTCompiler.UnCompiledNode<T> nodeIn)
}
if (targetHasArcs && (flags & BIT_TARGET_NEXT) == 0) {
- assert target.node > 0;
+ assert targetNode > 0;
Review comment:
> also - if we were able to encode negative offsets we could always apply this variable encoding
A negative offset would mean you target a node that has not been written yet. That's not possible by design. In addition it is not necessary, the way the fst is constructed is from the leafs to the root. A parent always has a higher offset than its child. Therefore negative offsets never happen.
Absolute vs. relative coding: I wasn't able to use relative addresses all times, if "fixed length arcs" are used I switch this optimization off completely. To always use relative coding I must replace all absolute addresses. I am not sure this is even possible.
When 1st experimenting with this technique years ago, I did some measurements and calculations. In smaller fst's absolute coding is sufficient, we have small addresses anyway. The larger the fst gets the more interesting relative coding becomes. If the fst is highly compressible the absolute address was often smaller than the relative one. E.g. leaf usually compress like that. For larger fst's and fst's that do not compress well (because of values) relative coding works nicely, because the construction yields good locality.
##########
File path: lucene/core/src/java/org/apache/lucene/util/fst/FST.java
##########
@@ -720,9 +745,9 @@ long addNode(FSTCompiler<T> fstCompiler, FSTCompiler.UnCompiledNode<T> nodeIn)
}
if (targetHasArcs && (flags & BIT_TARGET_NEXT) == 0) {
- assert target.node > 0;
+ assert targetNode > 0;
Review comment:
An absolute node address targeting `0` is not possible due to the reverse reading logic and that's the old assert anyway.
So the question remains, can a relative target be `0`?
In theory this would be a epsilon transition if I remember correctly. So the arc would follow a label and target itself like a regexp with a `*`, e.g. `a*`.
In practice I think such a regex-like matching functionality is not what this implementation is made for nor do I think it is possible at the moment. The nodes are constructed as `UncompiledNode`, but in order to make such an epsilon transition you need to know the target before you push it for persistence. In simpler words, this is a chicken-egg problem.
I know about some experimentation to use fst's as regexp engine, but at the moment I think this is not a problem. If it ever will be implemented other things have to be solved and at that time this assert can be removed.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org
[GitHub] [lucene] hendrikmuhs commented on pull request #460: LUCENE-10247 - reduce size of FSTs by relative coding
Posted by GitBox <gi...@apache.org>.
hendrikmuhs commented on pull request #460:
URL: https://github.com/apache/lucene/pull/460#issuecomment-975283052
Sorry, I somehow missed the `Draft` button, if a maintainer can turn this into draft, please do so.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org
[GitHub] [lucene] hendrikmuhs commented on a change in pull request #460: LUCENE-10247 - reduce size of FSTs by relative coding
Posted by GitBox <gi...@apache.org>.
hendrikmuhs commented on a change in pull request #460:
URL: https://github.com/apache/lucene/pull/460#discussion_r754601969
##########
File path: lucene/core/src/java/org/apache/lucene/util/fst/FST.java
##########
@@ -1000,6 +1027,98 @@ private void writePresenceBits(
assert bytePos - dest == numPresenceBytes;
}
+ private long estimateNodeAddress(
Review comment:
That's the trickiest part of the whole idea. I need to know [`thisNodeAddress`](https://github.com/apache/lucene/blob/main/lucene/core/src/java/org/apache/lucene/util/fst/FST.java#L779) before writing the state. But because everything uses variable length encodings, is based on flags, might write extra fields, etc. this is hard. I considered using the position of the arc, but, the compiler reverses the bytes it wrote (L780).
So what I ended up with is pre-calculating the node address ("estimate" is therefore wrong, feel free to suggest a better name, it must be exact (or return `0`, see below), so rather "precalculateNodeAddress").
Good to know: the heuristic is allowed to fail, in which case it returns `0` and relative coding isn't used.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org
[GitHub] [lucene] dweiss commented on a change in pull request #460: LUCENE-10247 - reduce size of FSTs by relative coding
Posted by GitBox <gi...@apache.org>.
dweiss commented on a change in pull request #460:
URL: https://github.com/apache/lucene/pull/460#discussion_r754563874
##########
File path: lucene/core/src/java/org/apache/lucene/util/fst/Outputs.java
##########
@@ -49,6 +49,20 @@
/** Encode an output value into a {@link DataOutput}. */
public abstract void write(T output, DataOutput out) throws IOException;
+ /** Get the required size of the output before writing */
+ // TODO: this must become abstract
+ public long outputSize(T ouput) {
+ return 1;
+ }
+ ;
Review comment:
Extra semicolons.
##########
File path: lucene/core/src/java/org/apache/lucene/util/fst/FST.java
##########
@@ -1000,6 +1027,98 @@ private void writePresenceBits(
assert bytePos - dest == numPresenceBytes;
}
+ private long estimateNodeAddress(
Review comment:
I can't quite grasp the logic here - have to go back to the fst compiler about why it's needed, it's been a while.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org
[GitHub] [lucene] rmuir commented on a change in pull request #460: LUCENE-10247 - reduce size of FSTs by relative coding
Posted by GitBox <gi...@apache.org>.
rmuir commented on a change in pull request #460:
URL: https://github.com/apache/lucene/pull/460#discussion_r754721280
##########
File path: lucene/core/src/java/org/apache/lucene/util/fst/FST.java
##########
@@ -720,9 +745,9 @@ long addNode(FSTCompiler<T> fstCompiler, FSTCompiler.UnCompiledNode<T> nodeIn)
}
if (targetHasArcs && (flags & BIT_TARGET_NEXT) == 0) {
- assert target.node > 0;
+ assert targetNode > 0;
Review comment:
you can decode/encode signed deltas with `read/writeZInt()`, `BitUtil.zigZagDecode(readVLong())` and similar.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org
[GitHub] [lucene] hendrikmuhs commented on a change in pull request #460: LUCENE-10247 - reduce size of FSTs by relative coding
Posted by GitBox <gi...@apache.org>.
hendrikmuhs commented on a change in pull request #460:
URL: https://github.com/apache/lucene/pull/460#discussion_r754601969
##########
File path: lucene/core/src/java/org/apache/lucene/util/fst/FST.java
##########
@@ -1000,6 +1027,98 @@ private void writePresenceBits(
assert bytePos - dest == numPresenceBytes;
}
+ private long estimateNodeAddress(
Review comment:
That's the trickiest part of the whole idea. I need to know [`thisNodeAddress`](https://github.com/apache/lucene/blob/main/lucene/core/src/java/org/apache/lucene/util/fst/FST.java#L779) before writing the state. But because everything uses variable length encodings, is based on flags, might write extra fields, etc. this is hard. I considered using the position of the arc, but, the compiler reverses the bytes it wrote.
So what I ended up with is pre-calculating the node address ("estimate" is therefore wrong, feel free to suggest a better name, it must be exact (or return `0`, see below), so rather "preCalculateNodeAddress").
Good to know: the heuristic is allowed to fail, in which case it returns `0` and relative coding isn't used.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org
[GitHub] [lucene] dweiss commented on a change in pull request #460: LUCENE-10247 - reduce size of FSTs by relative coding
Posted by GitBox <gi...@apache.org>.
dweiss commented on a change in pull request #460:
URL: https://github.com/apache/lucene/pull/460#discussion_r754613632
##########
File path: lucene/core/src/java/org/apache/lucene/util/fst/FST.java
##########
@@ -1000,6 +1027,98 @@ private void writePresenceBits(
assert bytePos - dest == numPresenceBytes;
}
+ private long estimateNodeAddress(
Review comment:
Thanks. I got the intuition right but some parts of this code were written while I was... away (including byte reversals during serialization), hence the uncertainty. I keep wondering if there is any other way to get those deltas... or make the deltas refer to a different placeholder. I recall tricks like this done back in assembly days on Amigas; basically you had a two-level data structure - a stream of bytes + known-size "placeholders" for compacting.
data stream: byte1 byte2 byte3 ... byteN byteN+1 ...
address placeholder: (data stream@N), (data stream@M), ...
Each placeholder is a fixed-size offset - the compacting routine receives the full data stream + placeholders so it has the ability to compute deltas (from left to right or from right to left) and shift-compact the data stream without knowing anything about the other data bytes. This way you sort of postpone the delta-offset computation until you know all of the data and the upper bound for its size, then reduce.
I'm sure you gave it some thought too - it's just what popped in my head immediately when I saw your code. The requirement for those two extra methods on outputs + the need to measure each node (I'd call it explicitly - computeNodeAddress) is a bit worrying... but then - if there is no visible slowdown then perhaps I'm just overreacting...
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org
[GitHub] [lucene] msokolov commented on a change in pull request #460: LUCENE-10247 - reduce size of FSTs by relative coding
Posted by GitBox <gi...@apache.org>.
msokolov commented on a change in pull request #460:
URL: https://github.com/apache/lucene/pull/460#discussion_r754629656
##########
File path: lucene/core/src/java/org/apache/lucene/util/fst/FST.java
##########
@@ -720,9 +745,9 @@ long addNode(FSTCompiler<T> fstCompiler, FSTCompiler.UnCompiledNode<T> nodeIn)
}
if (targetHasArcs && (flags & BIT_TARGET_NEXT) == 0) {
- assert target.node > 0;
+ assert targetNode > 0;
Review comment:
isn't it possible for this to be zero now? We could have arcs that target the current node?
##########
File path: lucene/core/src/java/org/apache/lucene/util/fst/FST.java
##########
@@ -1000,6 +1027,98 @@ private void writePresenceBits(
assert bytePos - dest == numPresenceBytes;
}
+ private long estimateNodeAddress(
Review comment:
I would be leery of having a function (here) that must mimic the tortuous logic elsewhere - I'm amazed you were able to (mostly) faithfully reproduce it! Something indeed that adds an additional buffer with the ability to go back and "patch up" the addresses once enough data has been written would enable the logic to be maintained in one place - and then if we add some clever opto there later, it would just reflected in the variable encoding here? I confess I don't quite see all the way to the end of that, but if it could be made to work, I think the extra RAM and time spent during compilation would probably be OK.
##########
File path: lucene/core/src/java/org/apache/lucene/util/fst/FST.java
##########
@@ -720,9 +745,9 @@ long addNode(FSTCompiler<T> fstCompiler, FSTCompiler.UnCompiledNode<T> nodeIn)
}
if (targetHasArcs && (flags & BIT_TARGET_NEXT) == 0) {
- assert target.node > 0;
+ assert targetNode > 0;
Review comment:
also - if we were able to encode negative offsets we could always apply this variable encoding and avoid the need for a bit and conditional logic to check it
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org
[GitHub] [lucene] hendrikmuhs removed a comment on pull request #460: LUCENE-10247 - reduce size of FSTs by relative coding
Posted by GitBox <gi...@apache.org>.
hendrikmuhs removed a comment on pull request #460:
URL: https://github.com/apache/lucene/pull/460#issuecomment-975283052
Sorry, I somehow missed the `Draft` button, if a maintainer can turn this into draft, please do so.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org