[erlang-questions] Sharing data by reference

Yogish Baliga <>
Mon Mar 30 23:37:36 CEST 2009


Thanx a lot.. This worked like a charm.. Performance boost is 50x. Earlier I could get 11k fetches per second, now I can get 550k per second.

-- baliga

 "The quality of programmers is a decreasing function of the density of GOTO statements in the programs they produce." - Edsger W. Dijkstra

http://dudefrommangalore.blogspot.com/





________________________________
From: Tony Rogvall <>
To: Yogish Baliga <>
Cc: 
Sent: Monday, March 30, 2009 12:53:22 AM
Subject: Re: [erlang-questions] Sharing data by reference



On 30 mar 2009, at 01.49, Yogish Baliga wrote:
> 
> I read in this post
> 
> http://www.erlang.org/pipermail/erlang-questions/2009-March/042503.html
> 
> that compile time constants are in constant pool and are used by reference in each process. This works well for compile time constants. What about the the run-time constant, for example configuration read from the file. This configuration remains constant through-out the life time of the VM. Is it possible to put that in the constant pool and have a reference to it in each process instead of copying around?

A couple of years ago I implement a (yet an other) configuration system that
generated a module for some of the constants on the fly. At that time the
reason was to have a faster access to constants.

With the latest development using shared module constants this approach may
be even better.

Since compilation is a bit slow (compared to accessing the constants)
The rate the constants are updated should be slow :-)

The idea is basically:

- System change it's configuration.
- Generate some part of the configuration to a module.
- Compile and load that module.

If the configuration change is done asynchronously in a live system,  some code may require
a consistent view of constants in the generated module (The constants are related somehow).
Then a access function reference may come in handy, since it will be connected to
the module version that it was created with.

Example:

-module(my_globs).
-export([name/0, version/0, value1/0, value2/0]).

name() -> "System name".
version() -> "1.1".

value1() ->  100.
value2() -> 200.

%--
Assume that value1 MUST be less than value2. Then we MAY have a problem when if this module is reloaded
while executing the following code:

    true = my_globs:value1() <  my_globs:value2().

Since the configuration may be reloaded between the calls to my_globs!
If we add an access function to my_globs:

-module(my_globs).
-export([name/0, version/0, value1/0, value2/0]).
-export([access/0]).

name() -> "System name".
version() -> "1.2".

value1() ->  50.
value2() -> 100.

access() ->
    fun(value1) -> value1();
         (value2) -> value2()
    end.
% -

We can now use a transaction like test like:

    Access = my_globs:access(),
    true = (Access(value1) < Access(value2))

This will work as long the code is not reloaded twice during the evaluation of the 'Access' function.
In which case I guess the code would be killed anyway ;-)

Hope this may be useful idea.

/Tony

> 
> Thanx,
> -- baliga
> 
> 
> "The quality of programmers is a decreasing function of the density of GOTO statements in the programs they produce." - Edsger W. Dijkstra
> 
> http://dudefrommangalore.blogspot.com
> _______________________________________________
> erlang-questions mailing list
> 
> http://www.erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20090330/d59fd701/attachment.html>


More information about the erlang-questions mailing list