Static Map ( Keys known at compile time )

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Static Map ( Keys known at compile time )

Prakash Parmar-3
Hello All,

Does Erlang supports Static Maps ? Something like, All possible Keys of Map has to be define at compile time and Can not be added/deleted dynamically. 

In a project we have a record with ~50 element and their fields will be accessed/Modified multiple times through out the Business Logic flow. Though we are not storing it in Mnesia. Does replacing Record with Map will be better option in terms of performance ? 

The primary thing we want is Static Map. No one should add/delete Keys in Map. Is it Possible ? 

Thanks,
Prakash


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Static Map ( Keys known at compile time )

Frank Muller
/Frank

Hello All,

Does Erlang supports Static Maps ? Something like, All possible Keys of Map has to be define at compile time and Can not be added/deleted dynamically. 

In a project we have a record with ~50 element and their fields will be accessed/Modified multiple times through out the Business Logic flow. Though we are not storing it in Mnesia. Does replacing Record with Map will be better option in terms of performance ? 

The primary thing we want is Static Map. No one should add/delete Keys in Map. Is it Possible ? 

Thanks,
Prakash

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Static Map ( Keys known at compile time )

Frank Muller
Mochiglobal:


/Frank

Hello All,

Does Erlang supports Static Maps ? Something like, All possible Keys of Map has to be define at compile time and Can not be added/deleted dynamically. 

In a project we have a record with ~50 element and their fields will be accessed/Modified multiple times through out the Business Logic flow. Though we are not storing it in Mnesia. Does replacing Record with Map will be better option in terms of performance ? 

The primary thing we want is Static Map. No one should add/delete Keys in Map. Is it Possible ? 

Thanks,
Prakash

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Static Map ( Keys known at compile time )

Mikael Pettersson-5
In reply to this post by Prakash Parmar-3
On Mon, Apr 29, 2019 at 8:23 AM Prakash Parmar
<[hidden email]> wrote:
>
> Hello All,
>
> Does Erlang supports Static Maps ? Something like, All possible Keys of Map has to be define at compile time and Can not be added/deleted dynamically.
>
> In a project we have a record with ~50 element and their fields will be accessed/Modified multiple times through out the Business Logic flow. Though we are not storing it in Mnesia. Does replacing Record with Map will be better option in terms of performance ?

That depends.  In principle a record is faster because the
field-to-index mapping is a compile-time constant, so all you're left
with at runtime are element and setelement calls, which are O(1).  A
map OTOH has a dynamic key set so must indirect through a hash to
search tree.  For smaller mappings a record should always win.

However, your records are quite large, and you state that they're
updated multiple times.  While lookups (element calls) are as fast as
can be, updates are O(size(Tuple)).  Past some point, it becomes more
efficient to split the tuple into chunks to reduce update costs, at
the expense of slightly higher lookup costs.  What's optimal depends
very much on the job mix and the HW it's running on.

So for these large mappings, maps may very well be faster.  You'll
need to measure on your own job mix.
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Static Map ( Keys known at compile time )

Richard O'Keefe
It's not clear to me why you would have a record with
50 fields.  Imagine for a moment that Erlang's record
declaration syntax were generalised slightly:

'-' 'record' '(' <name> ',' <group> ')' '.'
where
  <group> = '{' (<field> | <group>)+',' '}'
  <field> = <name> ['=' <default expr>]

The generalisation here is allowing <group>s as well
as <field>s inside <group>s.  A nested group would be
a nested tuple with no element reserved for a tag.  So
-record(foo, {{a,b},{c,d}}).
means that a typical instance would look like
{foo,{A,B},{C,D}}.
The time to fetch a field would be proportional to the
number of groups it is in; the time to replace it would
be proportional to the sum of the sizes of the groups
it is.
Put nested fields into groups that are commonly read
or written together, and you trade a small increase
in read time for a large decrease in write time, with
automatic economisation in pattern matching, but needing
special attention from the compiler to fully economise
updates.

That would be a nice extension of Erlang records, letting
you make performance tradeoffs just by adding and removing
curly braces with no change to code elsewhere.

Unless/until that's implemented, do it manually.


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Static Map ( Keys known at compile time )

Kostis Sagonas-2
On 4/29/19 12:31 PM, Richard O'Keefe wrote:
> It's not clear to me why you would have a record with
> 50 fields.

Same here, of course.

>  Imagine for a moment that Erlang's record
> declaration syntax were generalised slightly:
>
> '-' 'record' '(' <name> ',' <group> ')' '.'
> where
>    <group> = '{' (<field> | <group>)+',' '}'
>    <field> = <name> ['=' <default expr>]
>
> The generalisation here is allowing <group>s as well
> as <field>s inside <group>s.  A nested group would be
> a nested tuple with no element reserved for a tag.  So
> -record(foo, {{a,b},{c,d}}).
> means that a typical instance would look like
> {foo,{A,B},{C,D}}.
> The time to fetch a field would be proportional to the
> number of groups it is in; the time to replace it would
> be proportional to the sum of the sizes of the groups
> it is.
> Put nested fields into groups that are commonly read
> or written together, and you trade a small increase
> in read time for a large decrease in write time, with
> automatic economisation in pattern matching, but needing
> special attention from the compiler to fully economise
> updates.
>
> That would be a nice extension of Erlang records, letting
> you make performance tradeoffs just by adding and removing
> curly braces with no change to code elsewhere.

I see very little benefit, if any at all, compared to the (natural, IMO)
alternative of using nested records for such use cases:

  -record(foo, {#grp1{a,b},#grp2{c,d}}).

which requires no language (or implementation) extension.

What am I missing?

Kostis
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Static Map ( Keys known at compile time )

Richard O'Keefe
The advantage over nested records is fourfold.
Clarity: the factoring of a "record" into a nest of tuples
is invisible in the source code.  Use Foo#R_F rather than
Foo#R_F#N_G.  Easier to read.
Maintainability: changing the factoring does not affect
the field names.  Only the record declaration changes.
Space: the nested groups do not have tags.  If you have
say a 10-slot record containing 10 5-slot records, you
need 82 words.  With nested groups, you save 10 words,
or about 12% of the space.
Time: with tag-less nested groups, copying time is less.

Of COURSE nested records are a good approach right now.
It could just be a bit better.




On Tue, 30 Apr 2019 at 07:32, Kostis Sagonas <[hidden email]> wrote:
On 4/29/19 12:31 PM, Richard O'Keefe wrote:
> It's not clear to me why you would have a record with
> 50 fields.

Same here, of course.

>  Imagine for a moment that Erlang's record
> declaration syntax were generalised slightly:
>
> '-' 'record' '(' <name> ',' <group> ')' '.'
> where
>    <group> = '{' (<field> | <group>)+',' '}'
>    <field> = <name> ['=' <default expr>]
>
> The generalisation here is allowing <group>s as well
> as <field>s inside <group>s.  A nested group would be
> a nested tuple with no element reserved for a tag.  So
> -record(foo, {{a,b},{c,d}}).
> means that a typical instance would look like
> {foo,{A,B},{C,D}}.
> The time to fetch a field would be proportional to the
> number of groups it is in; the time to replace it would
> be proportional to the sum of the sizes of the groups
> it is.
> Put nested fields into groups that are commonly read
> or written together, and you trade a small increase
> in read time for a large decrease in write time, with
> automatic economisation in pattern matching, but needing
> special attention from the compiler to fully economise
> updates.
>
> That would be a nice extension of Erlang records, letting
> you make performance tradeoffs just by adding and removing
> curly braces with no change to code elsewhere.

I see very little benefit, if any at all, compared to the (natural, IMO)
alternative of using nested records for such use cases:

  -record(foo, {#grp1{a,b},#grp2{c,d}}).

which requires no language (or implementation) extension.

What am I missing?

Kostis
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions