OpenEuphoria

Re: Berkeley DB -- anyone care?

• Posted by jordah at btopenworld.com Jan 06, 2003
• 480 views

The code in binary.e might seem slower because of the overhead involved in
call_proc(). The original routine was clearly tested on #euphoria and
clearly faster producing more compressed objects.

     My hard-disk got smoked so i lost all i had been building hopefully
mario Steele still has the original routines that were benchmarked

Jordah
----- Original Message -----
From: "Andy Serpa" <ac at onehorseshy.com>
To: "EUforum" <EUforum at topica.com>
Subject: RE: Berkeley DB -- anyone care?


>
>
> jordah at btopenworld.com wrote:
> >
> >
> > > Yes.  I actually use the modified routines from EDS for converting a
> > > Euphoria object to or from a string of bytes -- I posted them to this
> > > list a while back under a thread called "Useful code stolen from
Rob" --
> > > I converted the routines to operate on sequences & objects in memory
> > > instead of reading/writing to disk as EDS does.  They are useful for
all
> > > sorts of things actually (like my in-memory db project).
> >
> > Could u please benchmark them with my binary.e and see the outcome. One
> > known problem of binary.e is that it handles doubles as float32 so their
> > is
> > very little inaccuaracy. Also binary.e produces faster and more
> > compressed
> > objects than EDS does as far as i can remember.
> >
>
> I guess you missed that post -- I actually suggested to you in there
> that these routines might go faster than the ones you used in your
> peek/poke objects to memory library.  I benchmarked the compress (which
> I renamed object_to_bytes) and found it slightly faster than yours on my
> limited.  But I didn't test the decompress/bytes_to_object because mine
> works on a sequence of bytes and yours peeks from memory, so it wasn't
> quite a fair test and I was to lazy to bother, so yours may be faster on
> the other end, I don't know.  The include file I'm using is below
> (remember, this is basically Rob's code -- from the "newer, faster
> version" of EDS):
>
>
> obj_to_bytes.e
> -----------------------------------------
>
> include machine.e
>
> constant
> I2B = 249,   -- 2-byte signed integer follows
> I3B = 250,   -- 3-byte signed integer follows
> I4B = 251,   -- 4-byte signed integer follows
> F4B = 252,   -- 4-byte f.p. number follows
> F8B = 253,   -- 8-byte f.p. number follows
> S1B = 254,   -- sequence
> S4B = 255
>
> constant
> MIN1B = -9,
> MAX1B = 239,
> MIN2B = -power(2, 15),
> MAX2B =  power(2, 15)-1,
> MIN3B = -power(2, 23),
> MAX3B =  power(2, 23)-1,
> MIN4B = -power(2, 31)
>
> integer spt
> sequence cseq
>
>
> -- turbo int_to_bytes() & bytes_to_int()
> constant
> ib_addr = allocate(4),
> ib_peek = {ib_addr,4}
>
> global function int2bytes(atom i)
>     poke4(ib_addr, i)
>     return peek(ib_peek)
> end function
>
> global function bytes2int(sequence b)
>     poke(ib_addr, b)
>     return peek4u(ib_addr)
> end function
>
>
> -- local recursive function does the work
> function decomp()
>     integer c
>     sequence s
>     atom len
>     object result
>
>     c = cseq[spt]
>     spt += 1
>
>     if c <= 248 then
>         -- return small int
>         return c + MIN1B
>     end if
>
>     if c = I2B then
>         result = cseq[spt] + (#100 * cseq[spt+1]) + MIN2B
>         spt += 2
>         return result
>     elsif c = I3B then
>         result = cseq[spt] + (#100 * cseq[spt+1]) + (#10000 *
> cseq[spt+2]) + MIN3B
>         spt += 3
>         return result
>     elsif c = I4B then
>         result = bytes2int(cseq[spt..spt+3]) + MIN4B
>         spt += 4
>         return result
>     elsif c = F4B then
>         result = float32_to_atom(cseq[spt..spt+3])
>         spt += 4
>         return result
>     elsif c = F8B then
>         result = float64_to_atom(cseq[spt..spt+7])
>         spt += 8
<snip>

>
>