From: François-Xavier Houard <idefx_at_iname.com>
Date: Fri, 6 Sep 2002 19:18:29 +0200

On Fri, Sep 06, 2002 at 12:27:20PM -0400, John Wood wrote:
> >> Really? And when you want to do a search when the music is playing, you
> might have to wait 4-5 seconds to do the search, since the mpeg thread may
> be using all dynamic memory? I think not. <<
>
> With about 17k a second for MP3 data, that's about 80 search results. You
> probably need a fraction of that, so the wait will be well under a second.
> And that would be the WORST case scenario, how often will you search at the
> exactly the time when the decoder was reading at the very end of the buffer?
>
> You could turn that argument around and say that, if you're only losing a
> second of MP3 buffer by having it static then it's not worth making it
> dynamic. True, but I think there are other uses of dynamic memory also.
> Games for example, folder listing, playlist data. They could all be dynamic.
>
> You would have occasional pauses to allocate the memory, but the result
> would be a very efficient use of memory.

This is far from the knowledges I have, so, i can't enter too much the
discussion, but, if it can help I can say you what I use, and what i'd like
to use to get thinks really efficient.

for the database reading, i use a 512 char buffer.
i don't know for the moment how will the char input work, but it may either
take a dynamic buffer, either take a 255 char (would be sufficient)
and then, for the search, each token need 2 array, one of strlen(token),
and one of 255 char.
so, a pattern like "miles brew bitches" would take, for the search time
only, something like 800 bytes.
...
This is, for sure, the one very optimised version, with a simple strcasestr
search instead of the boyer-moore, it may take less than 50 byte, but it
would be slower.


So, if it helps you...
Bye
FX
>
>
Received on 2002-09-06