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

[Roman Haefeli]

Dear José 

Thanks for the hint. I was indeed aware of this library and would also
use it if I'd hit a memory limit and would be dealing with sound files.
It seems like purpose is to allow to store specifically sound more
efficiently, no so much arbitrary byte-level data (though one could
easily write an abstraction to store 2 bytes at one table16 index.

I was just curious to think about it since we have now a general way to
deal with files on a byte level, I wondered if there is a similarly
general way to deal with bytes in memory. Obviously, there are arrays,
though they eat away 8 times more than strictly necessary on today's
systems. I'll stick to them anyway.

Roman


On Thu, 2022-01-13 at 11:41 -0300, José de Abreu wrote:
> 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
> 
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20220114/0d51424c/attachment-0001.sig>