[erlang-questions] Introspecting the atom table

[Ulf Wiger]

Den 2006-12-21 02:54:47 skrev Yariv Sadan <yarivvv@REDACTED>:

> In ErlyWeb, I ran into a similar situation, where browser requests
> would have to be matched against controller/function names. What I did
> was create a gb_trees structure with string keys being the names of
> the valid controllers and the values being the equivalent atom values
> as well as lists of controller function names. Instead of converting
> controller/function names of incoming requests to atoms, ErlyWeb looks
> them up in the gb_trees structure for the application. This is how
> ErlyWeb avoids allocating atoms for incoming requests.

I don't think that performance will be much of an issue in this
particular application - whether you use gb_trees, dict, or
the atom table. The data set is likely to be reasonably small
(that is, not in the tens of thousand).

If the names actually correspond to function names, you can take
advantage of the fact that the function names of all loaded modules
exist in the atom table. Then, list_to_existing_atom/1 is a
blindingly fast way to test whether the name can possibly be a
valid function name. A problem is of course that you have to make
sure that the module is loaded first.

If you knew of a usable meta programming facility, you could
generate code for the mapping,

   valid_function_name(ControllerStr, FunctionStr) -> {M,F}

Since you'll be adding controllers at "operator frequency"
(i.e. it's a manual process), the compile time should be
negligible.

This way, you create the atoms once, when compiling and loading
the module, and the "lookup" becomes about as fast as you can
make it (except perhaps if you use binaries rather than strings).

BR,
Ulf W
-- 
Ulf Wiger