<div dir="ltr"><br><br>On Friday, March 25, 2016, Michael Truog <<a href="mailto:mjtruog@gmail.com" target="_blank">mjtruog@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <div><br></div>
    <tt>Having the build process generate the module file and the beam
      file seems decent.  There isn't a need to build the module
      dynamically (during runtime, upon startup) or store the unicode
      data in global storage due to the unicode changes being
      infrequent.   Then, if you do need to update due to unicode
      changes, you can always hot-load a new version of the module,
      during runtime and the usage of the module shouldn't have problems
      with that, if it is kept as a simple utility/library module.  This
      problem reminds me of the code at </tt><a href="https://github.com/rambocoder/unistring" target="_blank">https://github.com/rambocoder/unistring</a>
    and there might be overlap in the goals of these two repositories.<br>
  </div></blockquote><div><br></div><div><br></div><div>this is what the current release (1.2) does. But it doesn't compile in containers or machines =< 1GB. The build crash. This is why i'm looking at shipping a pre-compiled beam. or maybe include the data in a db. but for now my tests with a db file (ets) shows it's really slower 30-40ms vs 6ms using maps<span></span> and a pre-compiled beam. Also maps use less storage compared to simply using function pattern matching in the beam.</div><div><br></div><div>- benoît</div><div><br></div>
</div>