Loading ...
Sorry, an error occurred while loading the content.

Loading all sources versus piecemeal

Expand Messages
  • Greg Bezoff
    It was once suggested that PCGen just have each tab load the pieces of the sources it needs, and free them up when the user moves on to another tab. Thus,
    Message 1 of 4 , Nov 1, 2001
    • 0 Attachment
      It was once suggested that PCGen just have each tab load the pieces of
      the sources it needs, and free them up when the user moves on to another
      tab. Thus, PCGen would only ever have in RAM those sources it was
      currently using, reducing the swap load on machines with less RAM. I did
      some measurements on my machine to determine the feasibility of this. I
      came up with the following results.

      1. When PCGen loads all my sources, it has a memory footprint of about 20
      megabtyes above the size required by java and the .jar file.

      2. It takes PCGen almost exactly 6 seconds to load my sources from the .lst
      files and expand them into the 20 megabytes of in-memory structures.

      3. If these 20 megabytes are written contiguously to my swap file, it takes
      my system 3.5 to 4 seconds to read or write them. (ATA 100 hard drive
      reads/writes contiguous records at about 5.5 megabytes per second.)

      Conclusions:

      A. To swap the 20 megabytes out and back in again takes 7-8 seconds. To
      read it and expand it from .lst files over and over again takes about 6
      seconds. So, there is some slight performance gain to be obtained here.

      B. Vastly better is for PCGen to load and expand all its .lst files and
      write them to a temporary file on disk. Since I assume that PCGen does
      not make changes to character classes, feats, etc. while it is running,
      PCGen can just load what it needs when it needs it from disk and then
      discard it (as opposed to having something that never changes swapped out)
      when it is done with it. This would be exactly twice as fast on a system
      that is undergoing heavy swap and is also significantly faster than
      repeatedly reading and expanding the .lst files.

      Of course, both of the options only make any sense whatsoever on systems
      with small amounts of RAM. Such systems are becoming vanishingly rare
      these days.
      --------------------
      Greg

      "Life is like a sewer. What you get out of it depends on what you put into
      it."
    • bd_92@yahoo.com
      ... systems ... rare ... hardly..i still have a slew of machine with less than 128mbs of ram, and they need to run PCGEN. The smaller the memory footprint the
      Message 2 of 4 , Nov 1, 2001
      • 0 Attachment
        > Of course, both of the options only make any sense whatsoever on
        systems
        > with small amounts of RAM. Such systems are becoming vanishingly
        rare
        > these days.


        hardly..i still have a slew of machine with less than 128mbs of ram,
        and they need to run PCGEN. The smaller the memory footprint the
        better. I had to upgrade to more memory on most of the laptops for
        this reason.
      • merton_monk@yahoo.com
        One monkey wrench in this is that java is fairly bad at memory management. Okay, bad is a bad word... more like you don t have as much control over memory
        Message 3 of 4 , Nov 1, 2001
        • 0 Attachment
          One monkey wrench in this is that java is fairly bad at memory
          management. Okay, bad is a bad word... more like you don't have as
          much control over memory management as you do with other languages.
          Simply telling java to recycle memory is not a trivial undertaking.

          I think that we can address this issue in 2 ways:
          1. users who really need to minimize the memory footprint can cut
          down the lst files to exactly what they need - cut out any races from
          phbrace.lst they don't use, cut out the magic weapons they don't use,
          etc.
          2. we'll slowly make out objects more efficient in their memory usage
          - since most of us developer types tend to have workhorse machines,
          this is probably low priority and will be addressed by slowly over
          time.

          -Bryan
        • bd_92@yahoo.com
          ... from ... use, ... But in this instance when updates are made to the .lst file we would have to reedit them again. This would be tedious and time consuming.
          Message 4 of 4 , Nov 1, 2001
          • 0 Attachment
            > I think that we can address this issue in 2 ways:
            > 1. users who really need to minimize the memory footprint can cut
            > down the lst files to exactly what they need - cut out any races
            from
            > phbrace.lst they don't use, cut out the magic weapons they don't
            use,
            > etc.

            But in this instance when updates are made to the .lst file we would
            have to reedit them again. This would be tedious and time consuming.
            Some of the folk that use the low end boxes don't have time to that
            over and over as they are updated.

            > 2. we'll slowly make out objects more efficient in their memory
            usage
            > - since most of us developer types tend to have workhorse machines,
            > this is probably low priority and will be addressed by slowly over
            > time.



            Still trying to get this blasted NIC to work in the laptop to dl
            pcgen.jar file.

            this would be an ideal solution to create a PCGen Lite version that
            would have most of the guts ripped out and only the core files added.
            I wouldn't know which files you would need or use but I am sure
            someone has an idea. This way you could produce 2 versions of it and
            still proceeding on the main course, but once your new conversion is
            taken place in the upcoming versions then what does it do the memory
            allocation and usage?
          Your message has been successfully submitted and would be delivered to recipients shortly.