[erlang-questions] Ref counted binary in ETS

[Frank Muller]

Hmmm ... bigger to  lower the overhead ratio, right?

Question: is there any (6-words) overhead if a process send 512-bytes Bin
message to another one?

Frank.

Le Friday, October 28, 2016, Tony Rogvall <tony@REDACTED> a écrit :

> Simple, you may your 512 byte memory chunks bigger :-)
>
> /Tony
>
> > On 27 okt 2016, at 23:24, Frank Muller <frank.muller.erl@REDACTED
> <javascript:;>> wrote:
> >
> > Tony,
> >
> > Wow, 48-bytes is a huge overhead as N ~= 1000, and Every reader reads a
> binary 10x times or so per second.
> >
> > Can anyone please suggest a better strategy to efficiently share them
> with a lesser overhead?
> >
> > Frank.
> >
> > Le Thursday, October 27, 2016, Tony Rogvall <tony@REDACTED
> <javascript:;>> a écrit :
> > 1. A reference.
> >
> > It will however build a 6-word structure called ProcBin on the heap for
> every binary reference that you read.
> > On a 64 bit machine that will lead to a 48 byte overhead. Nearly 10%.
> >
> > /Tony
> >
> > > On 27 okt 2016, at 20:47, Frank Muller <frank.muller.erl@REDACTED
> <javascript:;>> wrote:
> > >
> > > Hi guys
> > >
> > > Suppose an ETS table with only 1 writer and N readers
> > > This table contains only large binaries (>64B) with the same size 512B
> exactly.
> > >
> > > The single writer update these Bins once a while.
> > > The N readers regularly read one of these Bins, but never
> change/update them.
> > >
> > > Questions: what a reader gets when reading a Bin from this ETS table:
> > >
> > > 1. a reference to that Bin
> > > 2. or a full copy of that Bin
> > >
> > > Hope someone can clarify this (with an example).
> > >
> > > Thank you
> > > Frank
> > >
> > > _______________________________________________
> > > erlang-questions mailing list
> > > erlang-questions@REDACTED <javascript:;>
> > > http://erlang.org/mailman/listinfo/erlang-questions
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20161027/2e843437/attachment.htm>