Efficiency of big return functions?

[Oliver Korpilla]

Hello.

Thanks for ALL responses.

On 27.08.2020 17:49, Mikael Pettersson wrote:
> On Thu, Aug 27, 2020 at 11:51 AM Oliver Korpilla <oliver.korpilla@REDACTED> wrote:
>> My question is - how do I efficiently return a big static value (a list
>> of maps with no parameters to change their construction) from a
>> function? Does BEAM optimize this? Or is the value constructed when the
>> function is called?
> A static term should become a compile-time literal.  When the code is loaded,
> that literal is put in the global literals pool, and the function's
> reference to that
> value is just a constant pointer.  So there's no run-time construction
> of that value.

This is perfect!

What we are doing so far with our configuration information is that...

* we load the original format (JSON, XML) and let it be transformed into
a literal of lists, maps, strings, bitstring, and numbers by the
respective parser.
* we then generate a module with functions to return those literals.
(Functions of the form with a function head head for each key.)

We've been doing this in elixir on the fly by having a default
implementation loaded (returning always the same no matter what key is
passed in) and then replacing the module at runtime with one containing
the actual information loaded after startup.

This has been the perfect way for sharing our JSON configuration data
around instead of passing static information from process to process,
but my concern was indeed that the 1MB (after parsing) XML file would
somehow be a problem.

But now I see we can "simply" make a function with a head for each
unique key (the "ideal" way of addressing but usually not our use case
for the data in the XML) and other functions for returning the lists and
if I understand your information right, performance will be good or at
least not incur construction cost.

Even if in the future the information should require an update it would
only do so at a very specific point in the system life cycle and this
could be handled by recompiling and loading that module again.

> Returning any value from a function call is just placing that value in
> a register.
> There is no allocation or copying of heap data during returns (or when passing
> such data as parameters to functions).
>
> Allocation and copying does occur when storing data in ETS, retrieving
> data from ETS,
> and when sending data to a process.

I just love immutability.

Thank you!
Oliver


--
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus