<<
SMP Performance Degraded

David Fries noted that on his machine, the viewer was relying on a single core more heavily than it had in the past, and overall performance was somewhat degraded. Some experimentation lead to the discovery that cutting his reported graphics memory in half improved performance and multiple core use. He shared a theory about why this may be in an in-world IM, but no fixes yet.
>>
https://wiki.secondlife.com/wiki/SLDev-Traffic_2#SMP_Performance_Degraded

For testing purposes, I'm sometimes using two instances of Second Life. I've got 2 GB of RAM, AMD 64 3800/X2, GeForce 7600GT (256MB), Windows 2000 SP4, all MS fixes installed, and nothing fancy running in the background.

After 30-40 minutes, both SL instances use up all existing RAM and the PC starts swapping permanently. Each SL then uses about 700-800 MB of RAM, sometimes one of them even uses up to 1 GB. And it's not that I'm doing much - just standing around and looking at the landscape. The performance degrades to about 25%, but the CPU usage is rather low: 20%. The reason for the bad performance is the permanent activity on the harddisk.

When exiting one of the SL instances, the remaining one runs smoothly again. When re-starting a second SL, it doesn't take much time until both use up all available physical memory and the performance degrades again.

I don't know what people are doing who only have 1 GB of RAM or even less. SL must be nearly unusable on those PCs.

Reducing the "graphics memory" in the preferences from 256 MB to 128 MB doesn't change much. SL then uses 600 instead of 700 MB after 15 minutes running time which in my opinion still is way too much for just standing around and doing nothing.

Would be nice if this could be fixed soon!

after standing in a crowded sim for a while the gl memory goes up to around 400 mb and the computer starts to swap (swap file size can go up to 1.2 gig) so when i turn the camera it gets very choppy. when i turn down the graphics memory in the options to 128 mb (i have 256 on my card) it sometimes helps to improve performance. i first noted that problem after the performance update (the last first look client)

using a windows xp pc with an ati x1600 and 1 gig ram

Despite the memory leaks, there is currently a logic in place, which allows for a rather large memory (system ram, not video ram) buffer for textures based on the video memory setting. It serves as a first level cache (before going to the disk cache) for textures and can grow up to 1.3 times the video ram (it will start small but as more textures appear, it will fill up to this size). The downside is that it not sufficiently capped by system ram size, which can actually result in slower execution because the system is doing exceess swapping.

it's described in https://jira.secondlife.com/browse/VWR-733

I'marking this as resolved/duplicate because it's most likely addressed by VWR-364 and VWR-733 which both are worked on and have patches attached.

Feel free to reopen with more details if you think this is not the case.