Firestorm is one hell of a memory hog

[LittleMe Jewell]

50 minutes ago, ChibiDragon007 said:

I filed a report on the JIRA page with screenshots from my computer. The in-world support group is of zero help, the support people according to what I was told can't handle viewer related issues like that. So I have to wait however long it is for a dev to answer my JIRA report. However in the FS Support Group, I'm apparantly not alone with the rampant memory leak issue. According to some other users I spoke to, they also are experiencing high memory usage on both Mac and Windows 10.

Please update this thread if you find out what is causing your memory usage.  I've been monitoring it recently - because a few folks have mentioned the memory thing - but I've not yet seen mine go above roughly 2 GB.  This past Friday I was popping all over the grid hitting the Black Friday sales, so I would have been pulling in far more textures that I typically do, and I still didn't go much above the 2 GB.  My Firestorm cache is set to the max of 9984 MB and my Texture buffer is set to 2048 MB.

[Solar Legion]

The main cache setting, LittleMe, is for physical disk space. 

The only RAM setting you can alter is the amount of VRAM dedicated to the Texture Buffer. 

[ChibiDragon007]

1 hour ago, LittleMe Jewell said:

Please update this thread if you find out what is causing your memory usage.  I've been monitoring it recently - because a few folks have mentioned the memory thing - but I've not yet seen mine go above roughly 2 GB.  This past Friday I was popping all over the grid hitting the Black Friday sales, so I would have been pulling in far more textures that I typically do, and I still didn't go much above the 2 GB.  My Firestorm cache is set to the max of 9984 MB and my Texture buffer is set to 2048 MB.

Mine has gone up over 3gb whenever I've run it. My settings were the ones that were automatically detected by the viewer, no changes made. I did experiment on my previous laptop by lowering complexities but that didn't do much to alleviate the problem. Along with the memory leaking it makes my Macbook Pro that I have now (and this is a fresh from the factory, brand new 2018 model) heat up like hell. A couple pictures attached for reference btw. Those were taken while ONLY Firestorm was running. That 5.76 number actually shot up to a whopping 6.9 at times.

[Whirly Fizzle]

9 hours ago, ChibiDragon007 said:

Mine has gone up over 3gb whenever I've run it.

That's not excessive memory for a 64bit viewer, depending on the scene you are in & the size of your inventory etc.
I'd say 3 GB is about average if you are in a scene with lots of high poly mesh. There is nothing worse for munching through memory then the typical super high poly unoptimized mesh you see frequently in SL.

If you have a large inventory, that will also eat into memory.  Each inventory item will take ~7kb of memory.

[bigmoe Whitfield]

1 hour ago, Whirly Fizzle said:

That's not excessive memory for a 64bit viewer, depending on the scene you are in & the size of your inventory etc.
I'd say 3 GB is about average if you are in a scene with lots of high poly mesh. There is nothing worse for munching through memory then the typical super high poly unoptimized mesh you see frequently in SL.

If you have a large inventory, that will also eat into memory.  Each inventory item will take ~7kb of memory.

I;ve had mine topping 9 before. but that's heck of a cache setting and full 1024 draw.  mainland o.o

[Whirly Fizzle]

13 minutes ago, bigmoe Whitfield said:

and full 1024 draw.  mainland o.o

Yep, that's one way to do it 🤯

[MoiraKathleen]

22 hours ago, ChibiDragon007 said:

Mine has gone up over 3gb whenever I've run it. My settings were the ones that were automatically detected by the viewer, no changes made. I did experiment on my previous laptop by lowering complexities but that didn't do much to alleviate the problem. Along with the memory leaking it makes my Macbook Pro that I have now (and this is a fresh from the factory, brand new 2018 model) heat up like hell. A couple pictures attached for reference btw. Those were taken while ONLY Firestorm was running. That 5.76 number actually shot up to a whopping 6.9 at times.

I'm curious - perhaps I don't understand something about how the information is being displayed, but isn't Firestorm only using 2.35 GB of that total memory use of 5.76 GB?  Or do all those other processes that are showing some amount of memory usage all disappear as well when you quit Firestorm?  I guess I'm wondering what the baseline memory usage is, when there are not any apps running. 

[ChibiDragon007]

On 11/27/2018 at 9:54 PM, moirakathleen said:

I'm curious - perhaps I don't understand something about how the information is being displayed, but isn't Firestorm only using 2.35 GB of that total memory use of 5.76 GB?  Or do all those other processes that are showing some amount of memory usage all disappear as well when you quit Firestorm?  I guess I'm wondering what the baseline memory usage is, when there are not any apps running. 

The memory only ever hits 5.76gb and up when Firestorm is active. If Firestorm is closed, then my laptop using maybe 2-3gb which is fairly normal. That screenshot is with no other program running aside from FS. Baseline usage for a Macbook Pro (at least the ones I've used) is around 2-3gb, sometimes a touch more if I'm doing some intense online browsing or what not.

However, since Firestorm is intensely CPU heavy rather than using the GPU like any normal program would, it puts a lot more strain on my Macbook Pro's system, regardless of settings I've used. I've come to the conclusion that I can't play SL anymore since I don't want to risk frying my laptop or something over a game. Now I can play other games on my Macbook Pro (WoW, Hearthstone, etc) which are optimized properly for the system and run well. Second Life on the other hand is a decade old 'game' that hasn't been optimized at all for modern hardware likely outside of the LL Viewer.

 

[MoiraKathleen]

31 minutes ago, ChibiDragon007 said:

The memory only ever hits 5.76gb and up when Firestorm is active. If Firestorm is closed, then my laptop using maybe 2-3gb which is fairly normal. That screenshot is with no other program running aside from FS. Baseline usage for a Macbook Pro (at least the ones I've used) is around 2-3gb, sometimes a touch more if I'm doing some intense online browsing or what not.

However, since Firestorm is intensely CPU heavy rather than using the GPU like any normal program would, it puts a lot more strain on my Macbook Pro's system, regardless of settings I've used. I've come to the conclusion that I can't play SL anymore since I don't want to risk frying my laptop or something over a game. Now I can play other games on my Macbook Pro (WoW, Hearthstone, etc) which are optimized properly for the system and run well. Second Life on the other hand is a decade old 'game' that hasn't been optimized at all for modern hardware likely outside of the LL Viewer.

 

Thanks for the clarification. 

[Callum Meriman]

Mine is sitting on 7.6GB just sitting in my home region, It grows very slowly over time. After being online 8 to 10 hours it will consume all of my 16GB of RAM and start swapping. As long as I remmeber to relog after 3 or 4 hours I am ok.

One of the leaks is IM's group chat. Each time I get a new one is 2-10MB of RAM burnt and never released.

Edited December 1, 2018 by Callum Meriman

[Rob Huntsman]

yeah they need to make a viewer thats not supporting 10+ year old graphics cards.

That is why firestorm sucks up your memory.

They're are not really "Supporting" newer graphic cards, but the cores/memory in your computer. It's quite annoying.

[Fionalein]

49 minutes ago, Haselden said:

yeah they need to make a viewer thats not supporting 10+ year old graphics cards.

That is why firestorm sucks up your memory.

They're are not really "Supporting" newer graphic cards, but the cores/memory in your computer. It's quite annoying.

write a better one

[Rob Huntsman]

15 hours ago, Fionalein said:

write a better one

My friend wrote this one, seems to work better. Idk if I should give it out though it's firestorm with some tweaks/animesh.

[Moderate Edit: Link Removed]

Edited December 4, 2018 by Dakota Linden
Moderator Edit: Exe link removed

[Whirly Fizzle]

7 hours ago, Haselden said:

My friend wrote this one, seems to work better. Idk if I should give it out though it's firestorm with some tweaks/animesh.

<LINK REMOVED>

You shouldn't really post that on this public forum.
How do you know that viewer doesn't phone home the users login info or is riddled with malware or a keylogger?

I would advise against anyone downloading that viewer.

Edited December 4, 2018 by Whirly Fizzle

[Norton Burns]

On 11/27/2018 at 4:02 AM, ChibiDragon007 said:

Mine has gone up over 3gb whenever I've run it. My settings were the ones that were automatically detected by the viewer, no changes made. I did experiment on my previous laptop by lowering complexities but that didn't do much to alleviate the problem. Along with the memory leaking it makes my Macbook Pro that I have now (and this is a fresh from the factory, brand new 2018 model) heat up like hell. A couple pictures attached for reference btw. Those were taken while ONLY Firestorm was running. That 5.76 number actually shot up to a whopping 6.9 at times.

You are mis-interpreting the information.

The total 'Memory Used' figure will usually continue to increase so long as there is memory left to use. Empty memory is wasted memory. Don't confuse this with a 'memory leak' - it is not leaking, it is behaving exactly as intended. The OS will keep any/all recently used items in RAM in case it is needed again. Even with SSD technology it is still thousands of times faster to grab data from RAM than it is to have to go back & fetch it from disk.

The memory pressure meter on the left is showing you have zero memory issues - it is still firmly in the green. You only start to struggle if that goes red; orange means it is starting to compress or page memory, but not yet an issue.

If you are lagging with the information you have given, then memory is not the cause of your lag.

Your computer heating up is due to CPU/GPU usage, not memory usage. This is quite normal for any graphics-intensive application like SL & your machine ought to be perfectly capable of cooling itself sufficiently by increasing fan speed. Make sure the airflow is unimpeded; don't rest it on a duvet;)

Edited December 4, 2018 by Norton Burns

[Dakota Linden]

11 hours ago, Haselden said:

My friend wrote this one, seems to work better. Idk if I should give it out though it's firestorm with some tweaks/animesh.

[Moderate Edit: Link Removed]

Greetings!

Please do not post links to .exe files on the forums. 

While we understand that as Open Source, the viewer allows users to tweak and modify the viewer to enhance features or options, we strongly recommend that users do not download and use any viewer that has been hashed together outside of the registered 3rd party viewers.

http://wiki.secondlife.com/wiki/Third_Party_Viewer_Directory

While Linden Lab does not verify the legitimacy or veracity of any 3rd party viewer code, those who are registered with Linden Lab must comply with the Third Party Viewer Policy and failure to comply has repercussions. 

If you are using a 3rd Party Viewer and wish to see additional features and functions added to the viewer, especially with Firestorm, we strongly recommend that you submit your request directly to the 3rd Party Viewer Developers. 

Firestorm has a long history with Second Life and from what I have seen and heard, they are dedicated to providing a viewer that meets the wants of their users. and will most likely be very happy to look into any request from their users. 

 

Edited December 4, 2018 by Dakota Linden

[Callum Meriman]

14 hours ago, Norton Burns said:

The OS will keep any/all recently used items in RAM in case it is needed again.

If we are talking about the 2.3GB number next to firestorm... nah. If you've done a malloc in c++ and you free that memory, then you DO NOT want the OS to retain it for reuse, and it's good programming practice to initialise it as well. Retain/reuse would be a "wonderfull" way to exploit as there would be no guarantee the memory contained data that was useful or was not compromised by another process.

Huge security hole.

Yes, it does keep things like the disk's allocation structure, it keeps some cache, it possibly keeps some shared libraries, but all of those are outside the amount reported against Firestorm anyway. That highlighted figure is memory the application has requested. It's not really recording ancillary memory used by the OS.

In all these OS X examples 2.35GB-ish isn't bad, considering all the mesh and graphics are loaded, in my 7GB and growing Linux example less so, but then, Linux isn't really actively developed so a leak that appears due to compiling for that OS isn't a huge worry as long as I restart every eight hours or so.

Edited December 4, 2018 by Callum Meriman

[Norton Burns]

10 hours ago, Callum Meriman said:

If we are talking about the 2.3GB number next to firestorm...

No, I'm talking about the total 'Memory Used' figure at the bottom. The top section is 'current usage' [it can be further expanded to show real, private, shared, purgeable & compressed memory details.] Memory Used includes what the OS is hanging onto in case it needs it again. It does include currently open items, but also anything retained. To the right, App Memory is 'currently live' & Wired is the OS etc. If you push your current usage into the orange or red, so it starts compressing memory, then it will also start dropping anything it doesn't actually need right now, before it starts to page, closing the gap between Used & App + Wired. I'm pretty sure that the sandboxing structure would not allow unauthorised access to anything it does retain.

The memory management on macOS is frankly a long way above my pay grade, but it does handle the task extremely well compared to other (unnamed) well-known OSes  & won't page unless it really has to, unlike the ones that start paging at 50% RAM usage  Although I'm currently running betas so reboot about once a week, I normally consider a month or two uptime to be fine without a reboot to fresh everything up.

Edited December 5, 2018 by Norton Burns
better screenshot, including SL

[Alyona Su]

6 hours ago, Norton Burns said:

No, I'm talking about the total 'Memory Used' figure at the bottom.

That's everything all together. What is shown next to Firestorm is what Firestorm is using. Though it appears that there are two instances of Firestorm running.  Unlike the *memory pig* that Firestorm seems to be on Windows (perhaps it's that paging thing you speak of) - Firestorm actually runs slick-as-snot on Mac in my experience (and never, ever crashes, go figure).

I suspect the OP of that chart is reading it incorrectly.

[Norton Burns]

27 minutes ago, Alyona Su said:

That's everything all together.

Please read the entire thread before commenting - that's exactly what I'm attempting to convey to people who are mis-interpreting the data.

[Alyona Su]

23 minutes ago, Norton Burns said:

Please read the entire thread before commenting - that's exactly what I'm attempting to convey to people who are mis-interpreting the data.

No need to read the entire thread since my reply was to you, not the thread.

[Norton Burns]

17 hours ago, Alyona Su said:

No need to read the entire thread since my reply was to you, not the thread.

Then you entirely missed the point.

[arabellajones]

On 12/4/2018 at 10:22 PM, Callum Meriman said:

 

In all these OS X examples 2.35GB-ish isn't bad, considering all the mesh and graphics are loaded, in my 7GB and growing Linux example less so, but then, Linux isn't really actively developed so a leak that appears due to compiling for that OS isn't a huge worry as long as I restart every eight hours or so.

I use Linux, and Firestorm can throw up some pretty high figures for memory use, multiple copies of SLPlugin and Dullahan at a couple of GB each, but that shows one of the dangers of these figures. A big chunk of the nominal 2GB is effectively read-only code and the multiple instances are pointers to the same piece of memory. If you did do a simple addition without taking such things into account it's 16GB and rising.

But Firestorm does use a lot more RAM than other viewers. I've used others, one of them Animesh-capable so I reckon the core of the program must be similar, which don't grab anything like as much. And, yes, I am talking about the same places, with the same people around. I remember how Firestorm was not a good choice for big events, in the days of 32-bit software, even with things such as draw distance at a minimum.

Don't forget, of course, that there are other things that have to run besides Firestorm. The Operating System, for one. I just looked up the official system requirements. The SL Viewer says 1GB minimum.

This seems ridiculous. I haven't been able to find any reference for Firestorm.

4GB seems to be the minimum physical RAM supplied in most current Windows machines, and on past experience I would say that sort of commercial minimum has always been barely adequate.

 

[KarraSue]

I have been getting this  message when I click on the lag meter " Client frame rate below 10- possible cause too many complex objects in scene.  Frame rate starts at approximately 32 fps, then steadily drops to about 3 fps. Issue started last Friday. Just what are complex objects, and how do I remove them

[Fionalein]

7 minutes ago, KarraSue said:

Just what are complex objects, and how do I remove them

Complex objects have many triangles, but it could as likely be texture abuse and it can be as well on avatars or rezzed objects. (removing those avatars is possible but they usually get angry when you kick them from your sim  ) Do not judge the real render complexity by the Avatar complexity number your viewer /and the LSL function) have. Those highly feature mesh - old sculptie and prim stuff is shown as having much more impact on your GPU than they really have. Same goes for Land impact. Ask @ChinRey for more details on that matter.