[erlang-questions] Sharing data by reference
Yogish Baliga
yogishb@REDACTED
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 <tony@REDACTED>
To: Yogish Baliga <yogishb@REDACTED>
Cc: erlang-questions@REDACTED
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
> erlang-questions@REDACTED
> 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.htm>
More information about the erlang-questions
mailing list