[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Raising awareness about guile-pfds status
From: |
Linus Björnstam |
Subject: |
Re: Raising awareness about guile-pfds status |
Date: |
Tue, 16 Jul 2019 09:07:21 +0200 |
User-agent: |
Cyrus-JMAP/3.1.6-731-g19d3b16-fmstable-20190627v1 |
On Mon, 15 Jul 2019, at 23:19, John Cowan wrote:
>
>
> On Mon, Jul 15, 2019 at 4:50 PM Linus Björnstam
> <address@hidden> wrote:
>
> > If it is HAMTs or persistent vectors you want, I have a git repo of Andy's
> > Fash and Fector (functional hashmaps and functional.vectors). Fash lacks
> > some parts to become a fast implementation of (srfi 146 hash),
>
> Is there a speed problem with the sample implementation of (srfi 146
> hash)? It's a HAMT package written by Art Gleckler.
I didn't mean to sound like I was criticizing Arthur's implementation. What I
meant was that fash currently lacks a fast way to delete keys. I could add a
<fash-null> value and set a deleted value to that, but I would like to do it
properly.
Fash and Fector also does some things differently from the other HAMTs/pvectors
I tried (note I did not try the reference implementation) that runs fast in
guile.
> Note that fectors are a bit specialized: they are very fast for both
> ref and set if you don't change the "current branch" very often, but
> slower if you do. Ordinary tree functional vectors have the same big-O
> no matter what. There will be a fector SRFI.
Compared to Bagwell's VLists pvectors/fectors are generally slower, but adds
the ability to set arbitrary values. I have been playing with the idea to
create a fast, thread safe VList library with support for transients as I
suspect it would be a slightly less capable, but much faster, alternative to
fectors. Andy's fectors are actually faster than guiles VLists for everything
except random access, but making the VLists support transients (and a way to
iterate without using indexes) would change that.