[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: out-of-memory handling
From: |
Bruno Haible |
Subject: |
Re: out-of-memory handling |
Date: |
Sun, 11 Oct 2020 13:56:38 +0200 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-189-generic; KDE/5.18.0; x86_64; ; ) |
Marc Nieper-Wißkirchen wrote:
> I am not so convinced of whether it makes sense to create a
> gl_set/gl_map frontend for this hamt implementation.
Wikipedia [1] lists some advantages of HAMTs even without the persistence.
> It is optimized
> for the persistence (otherwise, use ordinary hash tables), while the
> gl_set/gl_map interface is for destructive updates.
How would a HAMT implementation look like that does not support persistence,
but is instead optimized for destructive updates? Probably the reference
counters would go away. Anything else?
Bruno
[1] https://en.wikipedia.org/wiki/Hash_array_mapped_trie#Advantages_of_HAMTs
- Re: HAMT iterator, (continued)
- Re: HAMT iterator, Bruno Haible, 2020/10/11
- Re: HAMT iterator, Marc Nieper-Wißkirchen, 2020/10/11
- Re: HAMT iterators, Bruno Haible, 2020/10/11
- Re: HAMT iterators, Marc Nieper-Wißkirchen, 2020/10/11
- Re: HAMT iterators, Bruno Haible, 2020/10/11
- Re: out-of-memory handling, Bruno Haible, 2020/10/11
- Re: out-of-memory handling, Marc Nieper-Wißkirchen, 2020/10/11
- Re: out-of-memory handling,
Bruno Haible <=
- Re: out-of-memory handling, Marc Nieper-Wißkirchen, 2020/10/11
- Re: HAMT for gl_set and gl_map, Bruno Haible, 2020/10/11
- Re: [New module] Persistent Hash Array Mapped Tries (HAMTs), Marc Nieper-Wißkirchen, 2020/10/11
- Re: Draft #3 (with iterators), Marc Nieper-Wißkirchen, 2020/10/11
- Re: Draft #3 (with iterators), Bruno Haible, 2020/10/11
- Re: Non-opaque hamt type?, Marc Nieper-Wißkirchen, 2020/10/12
- Re: Non-opaque hamt type?, Bruno Haible, 2020/10/18
- Re: Non-opaque hamt type?, Marc Nieper-Wißkirchen, 2020/10/18
- Re: Non-opaque hamt type?, Bruno Haible, 2020/10/18
- Re: Non-opaque hamt type?, Marc Nieper-Wißkirchen, 2020/10/18