From: Benjamin Purcell <benjapurcell@gmail.com>
To: 9front@9front.org
Subject: Re: [9front] New Balanced Search Tree Implementation
Date: Mon, 12 Dec 2016 00:40:38 -0600 [thread overview]
Message-ID: <CAAsuYKcQbM0cpYBpYsBpTjSxeAwCqU4KWhHHzSdQjka7z4_s4g@mail.gmail.com> (raw)
In-Reply-To: <CAOgwaMucegZJC6vW=8=3mGJ0iWs0Njr7t5unW7QVayMo0uKHQg@mail.gmail.com>
I'm giving it a lucent public license
On Mon, Dec 12, 2016 at 12:38 AM, Mehmet Erol Sanliturk
<m.e.sanliturk@gmail.com> wrote:
>
>
> On Sun, Dec 11, 2016 at 10:30 PM, Benjamin Purcell <benjapurcell@gmail.com>
> wrote:
>>
>> I have written a binary search tree C library for Plan 9. It contains
>> implementations of both left leaning red-black trees and AVL trees.
>> In short, you create an AVL tree with
>>
>> Bsttree *t = bstcreate(AVL, cmp);
>>
>> and an LLRB tree with
>>
>> Bsttree *t = bstcreate(LLRB, cmp);
>>
>> Cmp is a comparison function. All other implementation details are
>> hidden from the user.
>>
>> I intend to replace libavl with this library for the following reasons
>> (details can be found below):
>>
>> 1. You get a choice of BST with a single API.
>> 2. The AVL implementation is much faster.
>> 3. The AVL implementation is smaller and less complicated.
>> 4. The API is easier to use.
>>
>> Item 1. is self-explanatory.
>>
>> Item 2.
>> Measurements of the new AVL implementation against the old one shows
>> that on average:
>> Insertion is 21.9% faster.
>> Deletion is 23.9% faster.
>> Lookup is 14.95% faster.
>> 10 trials were conducted on random keys. Sequential keys show similar
>> results.
>>
>> Item 3.
>> As for code size, the new AVL implementation plus walk code -- which
>> is shared with the LLRB tree -- comes to 362 source lines of idiomatic
>> C. The old AVL implementation 436 lines. The old implementation also
>> contains more functions, and calls many of them unnecessarily.
>> Despite the fact that it has more functions, the individual functions
>> themselves are more complicated.
>>
>> Item 4.
>> The AVL implementation's api has the following signatures expressed as
>> abstract types:
>>
>> Avl *(*)(Avltree*, Avl*);
>> Avl *(*)(Avltree*, Avl*, int);
>> Avl *(*)(Avlwalk*);
>> Avltree *(*)(int(*)(Avl*, Avl*));
>> Avlwalk *(*)(Avltree*);
>> void (*)(Avltree*, Avl*, Avl**);
>> void (*)(Avlwalk*);
>>
>> Duplicate signatures have been removed in the above. The new bst
>> implementation has the following de-duped signatures:
>>
>> Bst *(*)(Bsttree*);
>> Bsttree *(*)(int, int(*cmp)(Bst*, Bst*));
>> Channel *(*)(Bsttree*, Bst*, Bst*, int);
>>
>> but maintains the same functionality. Which API would you rather use?
>>
>> The code can be found at the following locations:
>>
>> /n/contrib/spew/libbst
>> https://bitbucket.org/spewspews/libbst
>> https://github.com/spewspews/libbst
>>
>> A full man page is include and various tests are included in src/tests
>> including measurements of AVL vs. LLRB, and the new AVL implementation
>> against the old.
>>
>> If there are no objections I would like to remove libavl and add
>> libbst instead. Libavl has no usages in the source tree. If anyone tries
>> to compile a libavl program then tough. There will be a better
>> implementation available and we can always keep it available in
>> contrib or extra.
>>
>> Spew
>
>
>
>
>
> There is no license information file in
>
> https://github.com/spewspews/libbst
>
>
> means , it can not be used in any way or manner .
>
>
>
> Thank you very much .
>
>
> Mehmet Erol Sanliturk
>
>
>
>
>
next prev parent reply other threads:[~2016-12-12 6:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-12 6:30 Benjamin Purcell
2016-12-12 6:38 ` [9front] " Mehmet Erol Sanliturk
2016-12-12 6:40 ` Benjamin Purcell [this message]
2016-12-12 14:30 ` cinap_lenrek
2016-12-12 15:36 ` Steve Simon
2016-12-12 16:24 ` Benjamin Purcell
2016-12-12 16:32 ` cinap_lenrek
2016-12-12 16:36 ` cinap_lenrek
2016-12-12 17:18 ` Benjamin Purcell
2016-12-12 18:02 ` Benjamin Purcell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAAsuYKcQbM0cpYBpYsBpTjSxeAwCqU4KWhHHzSdQjka7z4_s4g@mail.gmail.com \
--to=benjapurcell@gmail.com \
--cc=9front@9front.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).