<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">You then have the choice of trying to
      tweak the GC with parameters to try and avoid consuming too much
      memory, but that only works if your throughput stays roughly the
      same (within what you expect), otherwise you then have to play
      with the GC settings again, based on a new throughput max... or,
      you can use a short-lived process to manipulate memory, such that
      the result is returned upon the short-lived process' death (the
      third option would be manually making garbage collection happen,
      which is dirty, but possible with
      <a class="moz-txt-link-freetext" href="http://www.erlang.org/doc/man/erlang.html#garbage_collect-0">http://www.erlang.org/doc/man/erlang.html#garbage_collect-0</a>).  So,
      using short-lived processes to facilitate the work of longer-lived
      processes is generally the solution to this problem.  Making an
      Erlang process is cheap, and using a short-lived process to help
      the GC know what memory is old, is a simple way of handling the
      problem.  If you use CloudI, the cloudi_service behaviour does
      this for you by default, when you receive service requests, with
      the request_pid_uses service configuration option
      (<a class="moz-txt-link-freetext" href="http://cloudi.org/api.html#2_services_add_config_opts">http://cloudi.org/api.html#2_services_add_config_opts</a>)... so it
      is part of CloudI's service abstraction.<br>
      <br>
      <br>
      On 02/17/2014 12:42 PM, Mahesh Paolini-Subramanya wrote:<br>
    </div>
    <blockquote cite="mid:etPan.53027437.7545e146.9c82@paglierino.home"
      type="cite">
      <meta http-equiv="Context-Type" content="text/html; charset=utf-8">
      <div id="bloop_customfont">“Large number of processes with very
        long persistence”</div>
      <div id="bloop_customfont"><br>
      </div>
      <div id="bloop_customfont">You *will* run into GC issues here, and
        of all kinds</div>
      <div id="bloop_customfont">   - design artifacts (“hmm, the number
        of lists that I manipulate increases relentlessly…”)</div>
      <div id="bloop_customfont">   - misunderstanding (“But I passed
        the binary on, without manipulating it at all!”)</div>
      <div id="bloop_customfont">   - Bugs (Fred has a great writeup on
        this somewhere)</div>
      <div id="bloop_customfont"> </div>
      <div id="bloop_customfont">Just keep in mind that in the end, you
        will almost certainly end up doing some form of manual GC
        activities.  Again, the Heroku gang can probably provide a whole
        bunch of pointers on this…</div>
      <div id="bloop_customfont"><br>
      </div>
      <div id="bloop_customfont">chees</div>
      <div id="bloop_sign_1392669504517230080" class="bloop_sign">
        <div>
          <div>
            <div><span><b>
                  <div><b><a moz-do-not-send="true"
href="http://www.gravatar.com/avatar/204a87f81a0d9764c1f3364f53e8facf.png"
                        target="_blank">Mahesh Paolini-Subramanya</a></b></div>
                  <div><span>That tall bald Indian guy..</span> <br>
                  </div>
                </b></span></div>
          </div>
          <div>
            <div><span><b>
                  <div>
                    <div>
                      <div><span>
                          <div><a moz-do-not-send="true"
                              href="https://plus.google.com/u/0/108074935470209044442/posts"
                              target="_blank">Google+</a><span>  | <a
                                moz-do-not-send="true"
                                href="http://dieswaytoofast.blogspot.com/"
                                target="_blank"><span>Blog</span></a></span> <span> 
                              | <span><a moz-do-not-send="true"
                                  href="https://twitter.com/dieswaytoofast"
                                  target="_blank">Twitter</a></span></span><span> 
                              | </span><a moz-do-not-send="true"
                              href="http://www.linkedin.com/in/dieswaytoofast"
                              target="_blank">LinkedIn</a></div>
                        </span></div>
                    </div>
                  </div>
                </b></span></div>
          </div>
        </div>
      </div>
      <br>
      <p>On February 17, 2014 at 3:22:22 PM, Miles Fidelman (<a
          moz-do-not-send="true"
          href="mailto://mfidelman@meetinghouse.net">mfidelman@meetinghouse.net</a>)
        wrote:</p>
      <blockquote type="cite" class="clean_bq"><span>
          <div>
            <div>Joe Armstrong wrote:
              <br>
              > This sounds interesting. To start wit, I think
              swapping processes to <br>
              > disk is just an optimization.
              <br>
              > In theory you could just keep everything in RAM
              forever. I guess <br>
              > processes could keep their state in dictionaries (so
              you could roll <br>
              > them back) or ets tables (if you didn't want to roll
              them back).
              <br>
              >
              <br>
              > You would need some form of crash recovery so
              processes should write <br>
              > some state information
              <br>
              > to disk at suitable points in the program.
              <br>
              <br>
              Joe... can you offer any insight into the dynamics of
              Erlang, when <br>
              running with large number of processes that have very long
              persistence? <br>
              Somehow, it strikes me that 100,000 processes with 1MB of
              state, each <br>
              running for years at a time, have a different dynamic than
              100,000 <br>
              processes, each representing a short-lived protocol
              transaction (say a <br>
              web query).
              <br>
              <br>
              Coupled with a communications paradigm for identifying a
              group of <br>
              processes and sending each of them the same message (e.g.,
              5000 people <br>
              have a copy of a book, send all 5000 of them a set of
              errata; or send a <br>
              message asking 'who has updates for section 3.2).
              <br>
              <br>
              In some sense, the conceptual model is:
              <br>
              1. I send you an empty notebook.
              <br>
              2. The notebook has an address and a bunch of message
              handling routines
              <br>
              3. I can send a page to the notebook, and the notebook
              inserts the page.
              <br>
              4. You can interact with the notebook - read it, annotate
              it, edit <br>
              certain sections - if you make updates, the notebook can
              distribute <br>
              updates to other copies - either through a P2P mechanism
              or a <br>
              publish-subscribe mechanism.
              <br>
              <br>
              At a basic level, this maps really well onto the Actor
              formalism - every <br>
              notebook is an actor, with it's own address. Updates,
              interactions, <br>
              queries, etc. are simply messages.
              <br>
              <br>
              Since Erlang is about the only serious implementation of
              the Actor <br>
              formalism, I'm trying to poke at the edge cases -
              particularly around <br>
              long-lived actors. And who better to ask than you :-)
              <br>
              <br>
              In passing: Early versions of Smalltalk were actor-like,
              encapsulating <br>
              state, methods, and process - but process kind of got
              dropped along the <br>
              way. By contrast, it strikes me that Erlang focuses on
              everything being <br>
              a process, and long-term persistence of state has taken a
              back seat. <br>
              I'm trying to probe the edge cases. (I guess another way
              of looking at <br>
              this is: to what extent is Erlang workable for writing
              systems based <br>
              around the mobile agent paradigm?)
              <br>
              <br>
              <br>
              <br>
              >
              <br>
              > What I think is a more serious problem is getting
              data into the system <br>
              > in the first place.
              <br>
              > I have done some experiments with document commenting
              and annotation <br>
              > systems and
              <br>
              > found it very difficult to convert things like word
              documents into a <br>
              > form that looks half
              <br>
              > decent in a user interface.
              <br>
              <br>
              Haven't actually thought a lot about that part of the
              problem. I'm <br>
              thinking of documents that are more form-like in nature,
              or at least <br>
              built up from smaller components - so it's not so much
              going from Word <br>
              to an internal format, as much as starting with XML or
              JSON (or tuples), <br>
              building up structure, and then adding presentation at the
              final step. <br>
              XML -> Word is a lot easier than the reverse :-)
              <br>
              <br>
              On the other hand, I do have a bunch of applications in
              mind where <br>
              parsing Word and/or PDF would be very helpful - notably
              stripping <br>
              requirements out of specifications. (I can't tell you how
              much of my <br>
              time I spend manually cutting and pasting from
              specifications into <br>
              spreadsheets - for requirements tracking and such.) Again,
              presentation <br>
              isn't that much of an issue - structural and semantic
              analysis is. But, <br>
              while important, that's a separate set of problems - and
              there are some <br>
              commercial products that do a reasonably good job.
              <br>
              <br>
              > I want to parse Microsoft word files and PDF etc. and
              display them in <br>
              > a format that is
              <br>
              > recognisable and not too abhorrent to the user. I
              also want to allow <br>
              > on-screen manipulation of
              <br>
              > documents (in a browser) - all of this seems to
              require a mess of <br>
              > Javascript (in the browser)and a mess of parsing
              programs inn the server.
              <br>
              >
              <br>
              > Before we can manipulate documents we must parse them
              and turn them <br>
              > into a format
              <br>
              > that can be manipulated. I think this is more
              difficult that the <br>
              > storing and manipulating documents
              <br>
              > problem. You'd also need support for full-text
              indexing, foreign <br>
              > language and multiple character sets and so
              <br>
              > on. Just a load of horrible messy small problems, but
              a significant <br>
              > barrier to importing large amounts
              <br>
              > of content into the system.
              <br>
              >
              <br>
              > You'd also need some quality control of the documents
              as they enter <br>
              > the system (to avoid rubbish in rubbish out), also to
              maintain the <br>
              > integrity of the documents.
              <br>
              <br>
              Again, for this problem space, it's more about building up
              complex <br>
              documents from small pieces, than carving up pre-existing
              documents. <br>
              More like the combination of an IDE and a distributed CVS
              - where fully <br>
              "compiled" documents are the final output.
              <br>
              <br>
              >
              <br>
              > If you have any ideas of now to get large volumes of
              data into the <br>
              > system from proprietary formats
              <br>
              > (like ms word) I'd like to hear about it.
              <br>
              >
              <br>
              <br>
              Me too :-) Though, I go looking for such things every once
              in a while, and:
              <br>
              - there are quite a few PDF to XML parsers, but mostly
              commercial ones
              <br>
              - there are a few PDF and Word "RFP stripping" products
              floating around, <br>
              that are smart enough to actually analyze the content of
              structured <br>
              documents (check out Meridian)
              <br>
              - later versions of Word export XML, albeit poor XML
              <br>
              - there are quite a few document analysis packages
              floating around, <br>
              including ones that start from OCR images - but they
              generally focus on <br>
              content (lexical analyis) and ignore structure (it's
              easier to scan a <br>
              document and extract some measure of what it's about -
              e.g. for indexing <br>
              purposes; it's a lot harder to find something that will
              extract the <br>
              outline structure of a document)
              <br>
              <br>
              <br>
              Cheers,
              <br>
              <br>
              Miles
              <br>
              <br>
              <br>
              -- <br>
              In theory, there is no difference between theory and
              practice.
              <br>
              In practice, there is. .... Yogi Berra
              <br>
              <br>
              _______________________________________________
              <br>
              erlang-questions mailing list
              <br>
              <a class="moz-txt-link-abbreviated" href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a>
              <br>
              <a class="moz-txt-link-freetext" href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a>
              <br>
            </div>
          </div>
        </span></blockquote>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
erlang-questions mailing list
<a class="moz-txt-link-abbreviated" href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a>
<a class="moz-txt-link-freetext" href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>