gb_trees (General Balanced Trees) 通用二叉查找树,通常被用作有序字典.与普通未平衡二叉树相比没有额外的储存开销,这里所说的额外的存储开销是指是否使用额外的metadata记录节点相关的信息,dict和array的实现就使用了这样的描述信息,换句话说gb_trees是自描述的.性能优于AVL trees. 相关论文: General Balanced Trees
  平衡二叉树(又称AVL树) ,左右子树的深度只差绝对值不超过1.这个插值称为平衡因子(balance factor),查找,插入和删除在平均和最坏情况下都是O(logn).节点的插入和删除平衡树失衡会触发重新平衡.重新平衡通过四种旋转实现:LL LR RR RL.gb_trees由于节点删除操作并不会增加树的高度,所以节点删除之后并没有进行再平衡.
 注:  gb_treess数据项比较使用的是相等==操作符.


Tree=  {Key, Value, Smaller, Bigger} |nil
Bigger=  Tree



Eshell V5.9.1  (abort with ^G)
1> G=gb_trees.
2> G:empty().
3> G:insert(k,v,G:empty()).
4> G:insert(k1,v1,v(3)).
5> G:insert(k2,v3,v(4)).
6> G:insert(k0,v0,v(4)).
7> G:insert(k0,v0,v(5)).
8> G:insert(k0,v0,v(6)).
** exception error: {key_exists,k0}
     in function  gb_trees:insert_1/4 (gb_trees.erl, line 321)
     in call from gb_trees:insert_1/4 (gb_trees.erl, line 283)
     in call from gb_trees:insert_1/4 (gb_trees.erl, line 300)
     in call from gb_trees:insert/3 (gb_trees.erl, line 280)
   insert操作会触发重新平衡balance(T);删除操作并不触发重新平衡,重新平衡方法大多数时候并不需要显示调用,这个接口暴露出来的目的是元素大量删除之后,通过重新平衡减少查询时间. insert(X, V, T)如果插入重复Key会引发 {key_exists,Key}异常;由于节点删除操作并不会增加树的高度,所以节点删除之后并没有进行再平衡.注意下面的比较:
Eshell V5.9.1  (abort with ^G)
1> T={8,{k,v,nil,{k1,v1,{k0,v0,nil,nil},{k4,v4,{k3,v3,nil,nil},{k5,v5,nil,{k6,v6,nil,{k7,v7,nil,nil}}}}}}}.
{k,v,nil,  {k1,v1, {k0,v0,nil,nil},   {k4,v4,  {k3,v3,nil,nil}, {k5,v5,nil,{k6,v6,nil,{k7,v7,nil,nil}}}}}}}
2> gb_trees:delete(k1,T).
{7,{k,v,nil,{k3,v3,{k0,v0,nil,nil}, {k4,v4,nil,{k5,v5,nil,{k6,v6,nil,{k7,v7,nil,nil}}}}}}}
3> gb_trees:balance(v(2)).
{7,{k4,v4,{k0,v0,{k,v,nil,nil},{k3,v3,nil,nil}}, {k6,v6,{k5,v5,nil,nil},{k7,v7,nil,nil}}}}


lookup(Key, {_, T}) ->
    lookup_1(Key, T).

%% The term order is an arithmetic total order, so we should not
%% test exact equality for the keys. (If we do, then it becomes
%% possible that neither `>', `<', nor `=:=' matches.) Testing '<'
%% and '>' first is statistically better than testing for
%% equality, and also allows us to skip the test completely in the
%% remaining case.

lookup_1(Key, {Key1, _, Smaller, _}) when Key < Key1 ->
    lookup_1(Key, Smaller);
lookup_1(Key, {Key1, _, _, Bigger}) when Key > Key1 ->
    lookup_1(Key, Bigger);
lookup_1(_, {_, Value, _, _}) ->
    {value, Value};
lookup_1(_, nil) ->
6> gb_trees:lookup(k1,T).
7> gb_trees:get(k1,T).



update(Key, Val, {S, T}) ->
    T1 = update_1(Key, Val, T),
    {S, T1}.

%% See `lookup' for notes on the term comparison order.

update_1(Key, Value, {Key1, V, Smaller, Bigger}) when Key < Key1 -> 
    {Key1, V, update_1(Key, Value, Smaller), Bigger};
update_1(Key, Value, {Key1, V, Smaller, Bigger}) when Key > Key1 ->
    {Key1, V, Smaller, update_1(Key, Value, Bigger)};
update_1(Key, Value, {_, _, Smaller, Bigger}) ->
    {Key, Value, Smaller, Bigger}.
 enter 是一个复合操作,相当于update_or_insert,存在就更新,不存在就插入:
enter(Key, Val, T) ->
    case is_defined(Key, T) of
     true ->
         update(Key, Val, T);
     false ->
         insert(Key, Val, T)
 is_defined/2,lookup/2,get/2 都是尾递归操作, keys(T)  values(T) 两个操作实现并非尾递归:
keys({_, T}) ->
    keys(T, []).

keys({Key, _Value, Small, Big}, L) ->
    keys(Small, [Key | keys(Big, L)]);
keys(nil, L) -> L.

values({_, T}) ->
    values(T, []).

values({_Key, Value, Small, Big}, L) ->
    values(Small, [Value | values(Big, L)]);
values(nil, L) -> L.
  smallest(T) largest(T) 顾名思义,取最小最大键值对,smallest/1,largest/1是尾递归实现.
 take_smallest(T): returns {X, V, T1} X,V是最小值对应的键值对,T1是去掉最小值后的新树.take_largest(T): returns {X, V, T1}也类似.
18> gb_trees:largest(T).
19> gb_trees:take_largest(T).
{k7,v7, {7, {k,v,nil, {k1,v1,{k0,v0,nil,nil},
20> gb_trees:smallest(T).
21> gb_trees:take_smallest(T).
{k,v,  {7,  {k1,v1,  {k0,v0,nil,nil},        {k4,v4,
take_largest({Size, Tree}) when is_integer(Size), Size >= 0 ->
    {Key, Value, Smaller} = take_largest1(Tree),
    {Key, Value, {Size - 1, Smaller}}.

take_largest1({Key, Value, Smaller, nil}) ->
    {Key, Value, Smaller};
take_largest1({Key, Value, Smaller, Larger}) ->
    {Key1, Value1, Larger1} = take_largest1(Larger),
    {Key1, Value1, {Key, Value, Smaller, Larger1}}.
12> gb_trees:next(gb_trees:iterator(T)).
13> {Key,Value,I}=gb_trees:next(gb_trees:iterator(T)).
14> {Key2,Value2,I2}=gb_trees:next(I).
15> gb_trees:iterator(T).
16> I.
iterator({_, T}) ->

iterator_1(T) ->
    iterator(T, []).

%% The iterator structure is really just a list corresponding to
%% the call stack of an in-order traversal. This is quite fast.

iterator({_, _, nil, _} = T, As) ->
    [T | As];
iterator({_, _, L, _} = T, As) ->
    iterator(L, [T | As]);
iterator(nil, As) ->



%% @spec enter(key(), value(), headers()) -> headers()
%% @doc Insert the pair into the headers, replacing any pre-existing key.
enter(K, V, T) ->
    K1 = normalize(K),
    V1 = any_to_list(V),
    gb_trees:enter(K1, {K, V1}, T).

%% @spec insert(key(), value(), headers()) -> headers()
%% @doc Insert the pair into the headers, merging with any pre-existing key.
%%      A merge is done with Value = V0 ++ ", " ++ V1.
insert(K, V, T) ->
    K1 = normalize(K),
    V1 = any_to_list(V),
    try gb_trees:insert(K1, {K, V1}, T)
        error:{key_exists, _} ->
            {K0, V0} = gb_trees:get(K1, T),
            V2 = merge(K1, V1, V0),
            gb_trees:update(K1, {K0, V2}, T)

%% @spec delete_any(key(), headers()) -> headers()
%% @doc Delete the header corresponding to key if it is present.
delete_any(K, T) ->
    K1 = normalize(K),
    gb_trees:delete_any(K1, T).


When should you use gb_trees over dicts? Well, it's not a clear decision. As the benchmark module I have written will show, gb_trees and dicts have somewhat similar performances in many respects. However, the benchmark demonstrates that dicts have the best read speeds while the gb_trees tend to be a little quicker on other operations. You can judge based on your own needs which one would be the best.

Oh and also note that while dicts have a fold function, gb_trees don't: they instead have aniterator function, which returns a bit of the tree on which you can call gb_trees:next(Iterator) to get the following values in order. What this means is that you need to write your own recursive functions on top of gb_trees rather than use a generic fold. On the other hand, gb_trees let you have quick access to the smallest and largest elements of the structure with gb_trees:smallest/1and gb_trees:largest/1.





2014-8-20 16:55:14补充

Björn Gustavsson, from the Erlang/OTP team and programmer of Wings 3D, suggests using gb_sets in most circumstances, using ordset when you need a clear representation that you want to process with your own code, and using sets when you need the =:= operator .  gb_sets, ordsets, and sofs all use the == operator to compare values; if you have the numbers 2 and 2.0, they’ll be seen as the same number .However, the sets module uses the =:= operator.