Michael Froh

I feel like we still don't have a great solution to the current problem, where real users who have low levels of traffic end up with search requests that spike...

I managed to fix those ones by replacing `get_ref` with `assume_init_ref`, since the MaybeUninit feature changed the name before it was finalized. Similarly, `get_mut` was renamed to `assume_init_mut`. I'll post...

Here's that PR: https://github.com/zhihu/rucene/pull/18

I did some rough benchmarks using the large synonym file attached to https://issues.apache.org/jira/browse/LUCENE-3233 The benchmark code and input is at https://github.com/msfroh/lucene/commit/174f98a91e8709ee66dc2ed84b5c0b54e1a10635 |Attempt|On-heap load|Off-heap load|Off-heap reload|On-heap process|Off-heap process|Off-heap reload process |-------|------------|-------------|---------------|---------------|----------------|-----------------------...

I decided to try experimenting with moving the output words back onto the heap, since I didn't like the fact that every word lookup was triggering a seek. Running now,...

@dungba88 -- I'm trying to resolve conflicts with your changes, but I'm a little stuck. I don't understand how we're supposed to use the FST APIs to write the FST...

> @msfroh > > As you only need to write the FST metadata, there is no need to create the FST. You can just call > > ``` > directory.writeMetadata(words.size(),...

> I could put a PR for the saveMetadata change if you prefer. I'll update to take care of that. Thanks for the pointers!

> I realized I also need the saveMetadata change for https://github.com/apache/lucene/pull/12985. Do you think we should make it a standalone PR and merge first? Otherwise I've cherry-picked from this PR...

@dungba88 - I forgot about this change for a while. Did you create a separate PR for the saveMetadata change? Should I?