[PD] Store data in memory more efficiently than in arrays

[José de Abreu]

Roman, maybe you could use iem16?

https://git.iem.at/pd/iem16 says that it is "16bit storage for Pd"

looking at the helpfile of [table16] we read:

"[table16] stores 16bit values. The normal pd-tables ([table], array) store
the values as floating-points. While floating points are (often) more
precise (this is of course not really true..., esp. when comparing
integer(4byte) to floating-point.) they use a lot of memory (4byte).

[table16] uses only 16bit (2bytes) to store the values, which is half of
the memory."

So maybe it is exactly what you need?

Em qua., 12 de jan. de 2022 às 11:57, Christof Ressi <info at christofressi.com>
escreveu:

> > I read
> > once in IRC that one value in a Pd-array requires not 4 bytes, but 8
> > bytes on 64-bit systems.
> Yes. Pd's graphical arrays (and Pd's data structure arrays in general)
> are implemented as a linear array of "words" (t_word). A "word" can hold
> one of several possible types. It is implemented as a C union, so the
> overall size is always that of the largest member. In our case, the
> largest member is a pointer (e.g. t_symbol *), which is 4 bytes on a
> 32-bit system and 8 bytes on a 64-bit systems.
>
> This means that even if you would add a "byte" type, the overall size of
> "t_word" would stay the same.
>
> However, you can always implement your own byte array object as an
> external. But as you noted, this is not necessary except you're on a
> very tight memory and/or CPU budget.
>
> Christof
>
> On 12.01.2022 14:20, Roman Haefeli wrote:
> > Hi
> >
> > Sometimes I stored byte data (lists of bytes) in arrays. IIRC, I read
> > once in IRC that one value in a Pd-array requires not 4 bytes, but 8
> > bytes on 64-bit systems. Since storing plain bytes seems not such an
> > uncommon use case for me, I wonder if it can be done more efficiently.
> > Not that I ever hit a memory limit, I'm just curious. With the new
> > (amazing!) [file] object, dealing with byte lists has become even more
> > appealing, so the desire to store them in memory increases.
> >
> >
> > Roman
> >
> >
> >
> > _______________________________________________
> > Pd-list at lists.iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20220113/c1b67377/attachment.htm>