Starfinder Playlist
Page 1 of 5 123 ... Last

Thread: Memory usage

  1. #1

    Memory usage

    My players have been having a larger than normal number of crashes lately. I assume I'm loading too much stuff so I started to experiment with memory usage.

    I have the server and client running on the same machine for these tests.

    With my current configuration the server is taking 1,355.1 MB of memory.

    I launch the client and join the local game.

    The client is using 3,195.2 MB of memory. Thinking it was maybe taking a while to compile (download) stuff, I let it sit for 10 minutes. No change.

    I started opening images on the client. Each time I opened and then closed an image the memory usage went down.

    Each time I close an image on the client the total memory used by the client drops by a few meg (the size of the image I assume).

    I really don't want to have to tell my players to go through and open/close images over and over again till their memory usage drops. Is there a better way to do this? Maybe a way to automatically open, the close each shared image?

    Is this just because of the fact that the client and server are on the same machine?

  2. #2
    I created a new campaign with nothing but the PHB.

    The client connected and was using about 1,000 MB. I went through and opened images one by one on the client. Each time I opened and then closed one for the first time the memory usage for the client dropped. Opening and closing the same image over and over had no extra effect.

  3. #3
    LordEntrails's Avatar
    Join Date
    May 2015
    Location
    -7 UTC
    Posts
    17,148
    Blog Entries
    9
    Yea, don't share so much stuff.
    No, it's not because you are on the same machine.
    The client is known to handle memory less efficient that the host.
    Images should normally not be larger than 2048x2048 pixels, file size should be kept below 2MB. JPG quality is typically best between 40-70%.
    Note that FG is a 32 bit application. So even if you have 64 GB of RAM, on a Windows machine FG will crash at about 3.3GB.

    All of these reasons are why SW has been working on porting FG to a 64 bit platform, but no ETA on when that will be released.

    Problems? See; How to Report Issues, Bugs & Problems
    On Licensing & Distributing Community Content
    Community Contributions: Gemstones, 5E Quick Ref Decal, Adventure Module Creation, Dungeon Trinkets, Balance Disturbed, Dungeon Room Descriptions
    Note, I am not a SmiteWorks employee or representative, I'm just a user like you.

  4. #4
    Doubling the amount of memory used for each graphic seems like it's more than just an efficiency problem though.
    Especially if the fix is as "easy" as "just" opening and closing each image one time.

  5. #5
    Trenloe's Avatar
    Join Date
    May 2011
    Location
    Colorado, USA
    Posts
    33,362
    Quote Originally Posted by LordEntrails View Post
    Images should normally not be larger than 2048x2048 pixels, file size should be kept below 2MB. JPG quality is typically best between 40-70&
    As an aside - the usual community consensus of image file size recommendations is 1MB or below, not 2MB. This is purely for speed of sharing with players, not the size the image takes in memory (this is based off the image resolution) - the larger the image file size is above 1MB in file size there is a bit of an exponential growth in file sharing speed. So, the recommendation is 1MB or less (the lower the better).
    Last edited by Trenloe; January 21st, 2018 at 01:17.
    Private Messages: My inbox is forever filling up with PMs. Please don't send me PMs unless they are actually private/personal messages. General FG questions should be asked in the forums - don't be afraid, the FG community don't bite and you're giving everyone the chance to respond and learn!

  6. #6
    Trenloe's Avatar
    Join Date
    May 2011
    Location
    Colorado, USA
    Posts
    33,362
    Quote Originally Posted by JohnQPublic View Post
    Especially if the fix is as "easy" as "just" opening and closing each image one time.
    That's an interesting finding. The client, in it's current architecture, has to essentially activate all shared resources to process them properly. Hence they are getting loaded into memory when the player starts up and the large player side memory footprint results.

    The recommendation from the devs has always been to limit what you share with players - especially when it comes to images/maps. I don't know if there is realistically anything the devs can do to simulate closing all of the image resources in the background once they've been activated - they'd have to comment on that aspect.
    Private Messages: My inbox is forever filling up with PMs. Please don't send me PMs unless they are actually private/personal messages. General FG questions should be asked in the forums - don't be afraid, the FG community don't bite and you're giving everyone the chance to respond and learn!

  7. #7

    Join Date
    Apr 2008
    Location
    Virginia Beach
    Posts
    3,096
    Quote Originally Posted by JohnQPublic View Post
    Doubling the amount of memory used for each graphic seems like it's more than just an efficiency problem though.
    Especially if the fix is as "easy" as "just" opening and closing each image one time.
    Not sure what you mean here, but remember that a displayed graphic in most architectures 'unpacks' the JPEG and takes linear memory for the graphic, so 2x the file size for a compressed jpeg is not unreasonable, especially if you think about the mask, if there is one.

  8. #8

    Join Date
    Jun 2013
    Location
    Isanti, MN
    Posts
    2,922
    In addition, you have to remember the way memory management works on most computer systems. When a process requests memory, it's allocated from unused memory ("the heap") and marked as used by that process. When the memory is no longer being used, it *remains* marked as used by that process until the process completely exits. Actually releasing the memory back to the OS while the process is still running is so rare that I can't think of any OS that does it.

    Note: this is done for security reasons - if memory gets released back to the OS and the process still has that memory reference stored somewhere, it can still access it. If the OS then gives that memory to another process to use, there is a chance that the original process could still read / change that memory without the new process knowing about it. There are memory locks that *should* prevent this from happening, but it's highly reliant on the hardware to implement correctly, and most OS developers just don't want to trust the hardware for that... :-)
    Last edited by Andraax; January 21st, 2018 at 02:33.

  9. #9
    Quote Originally Posted by Andraax View Post
    In addition, you have to remember the way memory management works on most computer systems. When a process requests memory, it's allocated from unused memory ("the heap") and marked as used by that process. When the memory is no longer being used, it *remains* marked as used by that process until the process completely exits. Actually releasing the memory back to the OS while the process is still running is so rare that I can't think of any OS that does it.
    I could easily be misunderstanding what you are saying, but what I'm seeing is that it (Fantasy Grounds) is releasing the memory every time an image is opened and closed. The memory usage of the client as reported by Task Manager (Win10 x64) drops after each image is opened and then closed. If I go through and open and close each and every image in the clients list, the client ends up being half what it was before going through the images. It seems to be loading every single image into memory when the client loads/connects and only releasing it when the image is issued a 'close' command, but Fantasy Grounds itself doesn't need to be closed.

    For example, I start the client and connect to the server. I have several modules loaded and available for the client.

    The server takes up 757.1 MB.

    The client takes 3,259.0 MB.

    I open an image in the client (a battlemap) and the memory usage for the client goes up to 3,266.3 MB.

    Then I close the image from the client and the memory usage drops to 3,184.8 MB. Lower than the original (way too big) size.

    By opening and closing each image in turn I can ratchet the memory usage down. There are 5 pages of images available to the client. Opening and closing each image in turn on the 1st page drops the client memory footprint down to 2,756.2 MB. That makes a huge difference. I'm not going to go through all 5 pages by hand but it's obvious that simply opening and closing each image available to the client would go a LONG way towards solving the memory crash issues that some people have.

  10. #10
    Zacchaeus's Avatar
    Join Date
    Dec 2014
    Location
    Scotland
    Posts
    20,737
    What Andraax is saying is that once the OS has allocated memory to FG that allocation remains until FG itself is closed. So in your case 3.2 GB of memory will be allocated and although closing images will use less memory the amount actually allocated to FG is still 3.2 GB even though memory use shows as 2.7 Gb. So if more stuff gets added during that session the memory allocated to FG will increase from 3.2Gb - not from 2.7Gb
    If there is something that you would like to see in Fantasy Grounds that isn't currently part of the software or if there is something you think would improve a ruleset then add your idea here https://www.fantasygrounds.com/featu...rerequests.php

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
DICE PACKS BUNDLE

Log in

Log in