[erlang-questions] Help with storing data in memory

Evans, Matthew <>
Tue Mar 23 14:34:11 CET 2010


I agree with this. Implement it as a binary with offsets in the binary block as pointers marking the MPEG GOP boundaries.



You could then use gb_trees to find the closest offset when provided with a requested DTS. So given a DTS query to gb_trees it would return the byte offset in the binary structure (MPEG data) that is closest to the requested DTS. You would actually need to modify gb_trees so that it returns the closest match, but this should be trivial. For example:





lookup_closest(Key, {_, T}) ->

    lookup_closest1(Key, T, 0).



lookup_closest1(Key, {Key1, Value, Smaller, _}, _OldValue) when Key < Key1 ->

    lookup_closest1(Key, Smaller, Value);

lookup_closest1(Key, {Key1, _Value, _, Bigger}, OldValue) when Key > Key1 ->

    lookup_closest1(Key, Bigger, OldValue);

lookup_closest1(_, {_, Value, _, _},_OldValue) ->

    {value, Value};

lookup_closest1(_, nil, Value) ->

    {closest, Value}.





Then you could use split_binary to remove the head of the binary structure to simulate a circular buffer.







-----Original Message-----
From:  [mailto:] On Behalf Of Bob Ippolito
Sent: Tuesday, March 23, 2010 8:15 AM
To: Max Lapshin
Cc: Adam Kelly; Erlang-Questions Questions
Subject: Re: [erlang-questions] Help with storing data in memory



On Tue, Mar 23, 2010 at 6:54 AM, Max Lapshin <> wrote:

> ets is of type ordered_set, because each client can read by Key from

> its own place in ets table and it needs to know ets:next for each Key.

>

> So, queue doesn't fit, because I need random access to frame list.

> Also, I'm afraid that array will not fit: when client seeks back in

> timeshift table, I need to find closest frame, with conditions:

> #video_frame{type = video, frame_type = keyframe, decoder_config =

> false, dts = DTS} when DTS =< RequestedDTS

>

> If use array, I will have to perform lookup through 40K of entries.

> However, maybe it is not bad? I need to test.



Use a binary search! Since it's used as a ring you'll have to slightly

modify the standard algorithm but all of the data is sorted and you

have cheap random access so there is no good reason to do a sequential

scan.



-bob



________________________________________________________________

erlang-questions (at) erlang.org mailing list.

See http://www.erlang.org/faq.html

To unsubscribe; mailto:




More information about the erlang-questions mailing list