[erlang-questions] [ANN] LETS - LevelDB-based Erlang Term Storage v0.5.3

[Joseph Norton]

Ciprian -

For encoding and then returning keys and values to the Erlang virtual machine, leveldb::Slice() is sufficient.  I didn't run any comparison tests but my assumption is that using std::string() requires (should require?) an extra memory allocation, copy, and deallocation for the std:string() object itself.

Joe N.


On Nov 21, 2011, at 8:14 PM, Ciprian Dorin Craciun wrote:

> On Mon, Nov 21, 2011 at 11:58, Joseph Norton <norton@REDACTED> wrote:
>> 
>> Ciprian -
>> 
>> Yes, your guess is correct.
>> 
>> Joseph Norton
>> norton@REDACTED
> 
> 
>    :D, but then the second question appears:
>    * does this affect the performance in any way? (from what I've
> seen in their code, they also use some kind of iterator to implement
> `Get`;)
>    * is there a reason not to use the `std::string`? (is it
> inefficient from the C++ point of view, or it is when combined with
> Erlang?)
> 
>    I'm not in any way criticizing your work (actually when I've
> studied the LevelDB code I also thought to use the iterator for
> reads).
> 
>    I just want to learn from your experience by not making the same
> mistake twice. :)
> 
>    Thanks,
>    Ciprian.
> 
> 
>> On Nov 21, 2011, at 3:09 PM, Ciprian Dorin Craciun wrote:
>> 
>>>    I've thrown a quick look over your code
>>> `https://github.com/norton/lets/blob/master/c_src/lets_nif.cc` -- as I
>>> also want to make a LevelDB binding, but in Go, and I wanted to see
>>> how you did it -- and I was curios about one thing: why you never use
>>> `db->Get` but always for read operations you use
>>> `db->NewIterator(...)`? (I guess it's because it doesn't return a
>>> `Slice` but a `std::string`?)