Jump to content

MLPV2 memory reduction


Lear Cale
 Share

You are about to reply to a thread that has been inactive for 4484 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Since viewers now can report parcel script memory usage etc., I've started working on reducing MLPV2's footprint.  Here are some of the things I've done so far (and posted to the MLPV2 group -- join the group if you want a copy to experiment with).  I'll be interested in feedback and suggestions about other things to consider.

Also, I haven't seen the memory usage stuff in the client yet.  I'm running an older one and need to update, but don't get much SL time these days.  I'll appreciate any tips or clues you think I should know about region/parcel/avatar memory usage.

Keep in mind the goal is to reduce the memory footprint, not (specifically) to increase the number of poses or positions.  However, I'm keeping an eye open for any improvements I can make there, too.

~menucfg, which reads the MENUITEMS.* notecards and sends the processed configs to ~menu, now reduces its memory to a small pad over the used memory before it shuts itself off.

MENUITEMS.* notecards can now contain MEMORY directives.  After receiving the configuration, ~menu sets its memory limit to the given value, and then reports the remaining avaliable memory.

POSITIONS.* notecards can now contain {MEMORY} directives.  The syntax is odd but I didn't want to eat into the memory available for positions.  After reading the positions, ~memory sets its limit to the given value and reports the remaining available memory.

I plan to do similar things for sequences and swaps.  In addition, I'll probably have ~swap reduce itself automatically if no swaps are configured.  It would be nice to be able to eliminate the ~swap script if you're not using swaps, but I tried that originally and kept getting hit by race conditions.

I had planned to change ~poser* scripts to mono and have them reduce their memory to a constant, but in Mono they take 17K, so I left them at their 16K which is always the case for LSO.  However, they actually take less room on a server in Mono because they use little data; most of the space is code and code segments are shared in Mono.  I may add a constant memory limit to them in case anyone recompiles them in Mono, or might change them to Mono "for the greater good" regardless of the fact that it would increase the apparent memory footprint.

~run sets its memory to a small constant.

~run sets its memory

I had other items on the todo list, which are in the .readme notecard in the MLPV2.5a example I posted on the MLPV2 group notices.  I can't get ingame at the moment.

Feedback please!  Let me know how this version appears in whatever script memory displays we have now, compared to previous versions.

Thanks!

Link to comment
Share on other sites

I have a copy and will be poking at it the next few days.

One issue that's not memory related but could be shoehorned into the overall release...  Currently props are rezed with a compleatly random listen channel.  It would be extreamly nice if they were on a predictable offset based on object uuid, so 3rd party plugins and scripts can also use the channel.

Link to comment
Share on other sites


Lear Cale wrote:

Also, I haven't seen the memory usage stuff in the client yet.  I'm running an older one and need to update, but don't get much SL time these days.  I'll appreciate any tips or clues you think I should know about region/parcel/avatar memory usage.

In V3 you can see the memory usage in the about land -> script info.

It shows it the same way inworld items do, 16k for any LSO script and 64 for any mono script, unless it has a memory limit, then it will show that.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 4484 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...