DelayQueue::shrink_to_fit

[tikue]

For long-lived processes, it'd be nice to be able to reclaim memory from DelayQueue. For example, a server may have short daily spikes in traffic, and after the spike is over, the server should try to lessen its memroy footprint.

It'd be nice if DelayQueue offered a shrink_to_fit method, like HashMap et all have.

Perhaps the implementation of DelayQueue already takes care of this, but it wasn't clear from the documentation, so I figured I'd check!

[Darksonn]

This seems like a good idea. One question is how to handle the Slab we have inside it, since its shrink_to_fit method may not be able to shrink it if large keys are in use.

[aym-v]

@Darksonn The soon to be released compact method added by tokio-rs/slab#60 will shrink the slab past its length. This might be a solution but the keys will be changed so a way must be found to match the old keys to the new keys. Another solution might be to completely re-allocate the slab but it will be the same problem with the keys.

[Darksonn]

Yeah, some solution to not break keys is going to be necessary.

[b-naber]

I'd be interested in working at his. I think we would need a bijective map for the Key <-> usize key values that were changed by the compact call of the slab. We could store a pointer to that map in Data and the closure passed to compact allows us to mutate that map. Is there a problem with using a crate for the bimap (because tokio try to minimize external crate dependency)? Or should we implement this ourselves?

[Darksonn]

I don't want to use a bimap because at that point you might as well just use a HashMap instead of a slab, at which point you can just call HashMap::shrink_to_fit and be done with it.

[b-naber]

Well but we'd only need to keep the re-mapped keys in the bimap. Unless we somehow modify the Key instances we give out or use these as key values in the wheel implementation, there is no alternative to using a bimap as far as I can tell.

[Darksonn]

Using a HashMap seems like a much better alternative than the bimap to me. I still don't love it though.

[halfzebra]

Hi @Darksonn!

I'd like to take a stab at this if you agree with replacing Slab with a HashMap.
Maybe there's a better data structure on your mind that would fin this use case?

Let me know what you think!

[Darksonn]

There was some discussion on this on the Tokio discord a few weeks ago. I would encourage you to read it. @b-naber maybe you can summarize?

[halfzebra]

Thanks for your reply, I think I might have found the discussion you are referring to, it looks like there is progress on this issue.

I'll look into something else 🙂

[b-naber]

Yes, Ive already implemented this, but haven't had time to fully test it yet. Sorry for not updating the progress here, hope you haven't invested too much time into this yet, @halfzebra.

[halfzebra]

@b-naber It looks like you've done a pretty good job so far!

Thanks for working on this 👍