Lag

[Sammy Huntsman]

I feel like on top of better mesh optimization on the creator. That the same principles be applied to textures and scripts. I mean unoptimized scripts and textures can also effect the lag issue as well.

[animats]

6 hours ago, ChinRey said:

Because it's a combination of technique, art, creativity, intuition, experience, strict logic and crazy out-of-the box thinking.

That's not really true of LODs. SL, though, has a special problem - meshes are optimized without textures.  For a textured mesh, there's an objective standard of LOD correctness. You render the high LOD and lower LOD to occupy the same amount of screen space, sized for the lower LOD, and compare the differences in the pixels. If the match is good from multiple angles, it's a good LOD. Also, if the images match like that, the switch is invisible to the user. In areas where the color is uniform, you can take out more detail.

SL, though, has to optimize meshes without textures. It doesn't know where the texture detail is. That's a problem.

Here's Unreal Engine's automatic LOD system:

Notice the settings for "Pixel error".  UE4 docs say: "Because the algorithm knows how much visual difference every edge collapse is adding, it can use this information to determine at what distance that amount of error is acceptable."

The SL uploader, both the old and new version, doesn't do that pixel by pixel comparison. So we don't get a good match between LODs, let alone a seamless one.

[Jennifer Boyle]

16 minutes ago, animats said:

SL, though, has to optimize meshes without textures. It doesn't know where the texture detail is. That's a problem.

So, why can't LL (compulsorily) optimize meshes after textures are applied?

[animats]

4 minutes ago, Jennifer Boyle said:

So, why can't LL (compulsorily) optimize meshes after textures are applied?

Ah. See, this is one of the quandaries of SL. In game development, this happens long before the game ships. In SL, you can change the texture of any object at any time, either from the menus or from a script. By then, it's too late to change the mesh. Every viewer in range already has a copy of the mesh.

The compute effort to regenerate optimized LOD meshes is high (several seconds of compute for the best optimizers), and that's a big load to add to the system. However, it's worth thinking about doing that on clothing changes, when the baking servers, separate from the sim servers, are doing the bakes-on-mesh work. But that's just an idea at this point. I think it's worth looking into, because unoptimized clothing is the worst drag on the rendering process. The land impact system, flawed though it is, keeps things from getting totally out of hand for non-avatars. Avatars, though...

Hard problem, big potential win. Roblox is working on it, as they add a full clothing system. You know it's getting serious when Roblox gets written up in Vogue Business. Roblox avatars used to be a joke, but they're moving forward rapidly.

 

[ChinRey]

8 hours ago, animats said:

OK, please make sure Vir Linden gets that message.

Paging @Vir Linden

Done!

[ChinRey]

2 hours ago, animats said:

Here's Unreal Engine's automatic LOD system:

But this isn't really automatic LoD generation, Animats. It's more semi-automatic with a large number of parameters defined by the user/creator.

Also, the reduction rate they achieve in the video is rather low. I suspect even GLOD could do a decent job if all it had to do was reduce 1850 tris/2017 vertices down to 1716/1943 but that doesn't really improve performance very much. It may even reduce performance since switching between LoD models is work for the computer too. Pause that video and then skip back and forth between about 0:30 and 1:10. Does it still look good to you? The tri/vertice count for a mid LoD model in SL could probably be a bit higher than the LoD 3 shown in the video but not as high as the LoD 2.

That being said, yes, it is impressive and much better than I would have expected.

 

2 hours ago, animats said:

But that's just an idea at this point. I think it's worth looking into, because unoptimized clothing is the worst drag on the rendering process.

Yes but changing the LoD generating process isn't going to make any difference to clothing since the entire LoD system is effectively disabled for fitted mesh anyway. It doesn't really matter how the LoD models are created or how good they are if they are never ever actually displayed on a computer screen.

[Jennifer Boyle]

Could incentives help? If avatars are the main resource hogs, which is certainly supported by everyday experience, could incentives to reduce their impact induce content creators to produce lower-impact content?

Currently, the limit on avatars in a region is a fixed number (except for the few extra premium members that can enter full regions). If that number were variable and were based on the impact of the avatars, it would some amount of incentive to lower it.

Or, could the server penalize high-impact avatars by discarding some amount of detail, with, perhaps, more liberal limits for premium accounts? Maybe if my impact was too high, the server would substitute a plain texture for my skin? THAT, would sure get my attention!

Edited October 8, 2021 by Jennifer Boyle

[animats]

8 hours ago, ChinRey said:

But this isn't really automatic LoD generation, Animats. It's more semi-automatic with a large number of parameters defined by the user/creator.

Also, the reduction rate they achieve in the video is rather low.

True, although most people probably use the default settings. The Unity mesh reducer has fewer user tuning parameters but can do a roughly comparable job. This reflects the target market. Unreal is used for big-budget AAA game titles, where people obsess over visual quality. Unity is used for second-tier projects and is easier to use but not quite as good visually.

So here's the Unity "just push the button to create LODs" system.

Unity's LOD system. Very easy user interface.

The SL mesh uploader should work roughly like this.

How much to reduce is another issue, closely tied to the LI computation, which is highly controversial. The current LI charging rewards very low lowest LODs too much.

Avatars have a different set of problems. A near-term solution is to use the existing avatar impostoring system. The higher the complexity of your avatar, the closer the distance at which it drops to avatar impostor mode. To see what that would look like, set "number of non-impostor avatars" to 3 or so in your viewer. Then go someplace with lots of avatars.

[ChinRey]

19 hours ago, animats said:

So here's the Unity "just push the button to create LODs" system.

Not quite "just push the button", I'd still call it semi automatic. The vertice relevance modifier in particular, is a manual function that seems very interesting and useful although I think I can see a way to improve it.

To avoid any misunderstanding, I'm all for computer assisted LoD model generation and I believe there's a lot to achieve there. But I do not believe a fully automatic reduction system for polylist meshes is an option and I think those to videos support that. Perhaps the most important parameter that should be user configurable (and is in both UE and Unity but not in SL) is the LoD swap distances.

 

19 hours ago, animats said:

The SL mesh uploader should work roughly like this.

I'm not absolutely sure about that but it certainly would have been a significant improvement compared to how the current viewer and the MO project viewer work.

 

19 hours ago, animats said:

How much to reduce is another issue, closely tied to the LI computation, which is highly controversial. The current LI charging rewards very low lowest LODs too much.

Yes but we have to be careful not to throw the baby out with the bathwater here. I've seen people saying that 25% reduction between LoD levels is what we should aim for and that's not nearly enough.

There's not much chance the LI formula is going to be upgraded anytime soon anyway so we have to just deal with it.

---

When LL introduced polylist meshes to SL - first with the simplified sculpts, later with the more elaborate system we simply call "mesh" - they regarded it as a supplement to the existing building materials and did not anticipate that they would become major parts of Second Life. I think they were right in principle there but they made two serious mistakes: they forgot that even secondary features need proper development (and documentation for the users) and they neglected the need to also upgrade the existing procedural assets to keep them relvant as the main option.

One thing that worries me when I read discussions about various "virtual worlds of the future" is that they tend to be so much foused on UE or Unity as the examples to follow or engines to use. Those two engines are actually quite old, UE even older than SL, and each was originally made to cater for the special needs of one specific computer game. Their developers have done an amazing job continuosly updating and upgrading them but they are still beginning to show their age. Most relevant in this context is that they are based almost exclusively on polylist mesh assets. For those familiar with old style 2D graphics, imagine a word processor that only uses bitmap fonts, no TrueType or Postscript. That's essentially what a polylist only 3D engine is.

There was a reason why I used that particular vase for the LoD generation test. I had a feeling it would become relevant later and thought I might as well post pictures right away. Here it is again:

On 10/7/2021 at 7:52 PM, ChinRey said:

This is my "math geek" vase. The profile (ie the circumference) is a plain superellipse, nothing more fancy than that. The tapering along the path is just a series of a few very basic curves. I originally made it to illustrate a few of the possibilities an upgraded prim system could offer. Add a few more profile options, add basic curves to the tapering modifier and implement composite paths. Three very simple additions to the system and the latter was even suggested by Avi Bar-Zeev himself. Those are only three of the many possible upgrades to prims, greatly increasing their usability.

I do not suggest that Prims 2.0 could completely replace polylist meshes in SL or other virtual realities. But it could be developed enough to become the main building material with mesh only used how it was originally intended in SL: for those few objects that can't really be made in any other way.

The advantages it this are many. There would be far less LoD issues, bandwidth requirements would drop a bit, building would become much easier and much more of it could be done in world. And there would be no backwards compatibility issues; existing content would not be affected at all, only new content would be more efficient and easier to make.

This is all about scene objects of course. Maybe I should have said something about avatars too. But this post is so long and nerdy already so I think I'll leave that for later.

Edited October 9, 2021 by ChinRey

[animats]

I've been talking about "silhouette protection", as Unreal Engine does it. It's possible to do that in Blender, by hand. Here's what it looks like.

Here's a simple but hard test case - a thin sheet with a bump in it.

Flat sheet. 480 triangles. Created by stretching a cube to 10m x 10m x 0.1m, then subdividing the big faces x10.

Bad mesh reduction with Blender's decimate. 14 triangles. If you use that algorithm with extreme reduction, this is what happens. Note that the outer edges of the sheet have been pulled in. This is why extremely low-poly LODs look so awful.

 

Silhouette protection, done by hand. Only the selected vertices and edges can be mesh-reduced. The outer edges, both vertically and horizontally, are exempted. Notice that the inward side of the bump is not protected, because it doesn't extend the silhouette.

Next, decimate as hard as we can, with the outer edges locked. Not too bad.

Final result, without the edges showing. 52 triangles. That's as far as you can go with Blender's decimate.

With a bit more hand work, you can get down to 32 with only minor changes to the silhouette. So that's where mesh reduction should stop.

You can play with this in Blender, using the Decimate command, followed by Limited Dissolve to merge planar triangles.

So that's what I was talking about. Mesh reduction needs to preserve the silhouette of the object, so things don't blank out at distance.

[ChinRey]

5 hours ago, animats said:

Final result, without the edges showing. 52 triangles. That's as far as you can go with Blender's decimate.

With a bit more hand work, you can get down to 32 with only minor changes to the silhouette. So that's where mesh reduction should stop.

I'm not sure if I follow you here. If the concave side of the bulge can be eliminated (and I do agree it probably can), it's dead easy to make a 36 tri/20 vert LoD model with no other distortion whatsoever and a 28 tri/16 vert one with much less distortion than your result. It can even be done almost automatically using Blender's limited dissolve function. The illustrations certainly show why it's generally a bad idea to use Blender's decimate modifier for LoD reduction an that's an important lesson many mesh makers need to learn

But it's beside your point of course. Looking beyond that, yes, generally the silhouette protection idea seems to make a lot of sense. I'd like to see more examples though.

---

For this specific model, the ideal simplification process would be in three steps:

1. Eliminate all "zero angle" vertices, that is the ones that don't affect the shape at all. This would reduce the tri count to 60 and the vertice count (assuming smooth bump and hard edges elsewhere) to 48 and should be applied even to the high LoD model.
2. Remove the tris that are so close to being collapsed they won't be visible anyway. Those are the edges of the cube. Tri/vert count: 52/32.
3. Remove the concave bulge. Tri/vert count: 36/20.

This is dead easy and requires so little thinking it hardly matters if it's done by a human or a computer. Even [insert name of popular SL designer] should be able to figure it out with a little bit of encouragement and/or coercion.

Apart from step 1 this process may not be ideal for all mesh objects of course but does it have to? Is there any particular reason why the uploader can't offer a small selection of simplification methods suitable for different kinds of objects? It can't be too big a selection of course and option has to be carefully selected and carefully developed but a selection of half different ones shouldn't be too hard to handle neither for a human or a silicone brain.

---

One thing I should have thought of long ago but didn't really occur to me until I saw these pictures is that automatic simplification tools like Blender's decimate modifier, GLOD and MeshOptimizer don't seem to make any attempt to preserve symmetry. Human brains tend to be obsessed with symmetry and often try to find it even where it doesn't exist. I'm beginning to think the usablility and quality of those simplification tools are seriously reduced by ignoring this factor.

---

Another important factor that can be a serious headache both for maunal and automatic LoD model generation, is how to handle the normals. I don't really have a good solution to this and it seems nobody else does either.

---

In a private chat Animats mentioned to me how silhouette protection when taken far starts to resemble impostors. Thinking back to the good results Animats' earlier experiments with impostors showed for some objects, maybe part of the solution would be to use more (and automatically generated) impostors for the meshes they work well for?

---

In any case, I do not think there is a "golden hammer" that will smooth out all the problems with LoD generation and LoD management. Different objects require different approaches.

Edited October 10, 2021 by ChinRey
Typos

[arton Rotaru]

On 10/8/2021 at 8:11 PM, animats said:

How much to reduce is another issue, closely tied to the LI computation, which is highly controversial. The current LI charging rewards very low lowest LODs too much.

That's still the main problem when it comes to LODs. No matter how awesome an automatic mesh reducer will be, if it doesn't go low enough for those who tend to use "zeroed out" LODs to get a very low land impact, and aren't willing to create those LODs by hand,  will just export zeroed out LODs on their own, and load those from file.

[Coffee Pancake]

On 10/7/2021 at 11:02 PM, Sammy Huntsman said:

I feel like on top of better mesh optimization on the creator. That the same principles be applied to textures and scripts. I mean unoptimized scripts and textures can also effect the lag issue as well.

Mesh optimization has its place, however, the focus for SL creators is Li, which is a land accounting and billing system.

SL rendering uses an excessive number of draw calls, there isn't much we can do about this without extensive processing on the client to "gamify" SL assets. This isn't done as SL assets can change frame to frame (processing is time consuming and the results could be out of date just as soon as they are finished) - Fully dynamic objects and bad performance go hand in hand. It wouldn't be SL without that functionality.

When it comes to avatars, animating all those rigged attachments is the rub, optimized meshes help render speed, but that's essentially messing about in the weeds for micro optimizations. (oh no, my car has bald tires and gets no grip, lets harass people about keeping the ash tray empty!)

The best optimization creators can do is limit the number of individual meshes and textures in use.

Fewer objects and fewer textures in total (not size) is the secret sauce for getting the most out of the render engine we have.

I would very much like to see a bigger textures and more than 8 faces per mesh. Remember, it's not the size of the textures/meshes that's the problem, it's the number of textures/meshes.

Again, objects and textures could be merged into bigger assets in the viewer, which would lead to fewer draw calls, but because both of those things can change frame to frame, the performance burden isn't likely to end in a net performance gain. 

 

Scripts .. eeeehhhh. No. That's a myth perpetuated by easily misinterpreted statistics.

Scripts run in a very tight sandbox, the numbers we get relate to the state of the whole sandbox, which really should be bigger and better provisioned.

The best script optimization is using fewer scripts. It really doesn't matter what the scripts are doing, the number of scripts does (and NOT because more scripts use more memory).

Simple example. Say you have a scripted project that really needs about 256kb of total space to operate. You only get 64kb per script. But breaking this down into separate scripts with all the necessary house keeping code and code duplication means you probably need 6-8 scripts rather than 4. This isn't bad because your 6-8 script bundle now uses way more memory, it's bad because the combined processing over head has gone up by several factors.

But again - Memory is NOT the problem. Scripts are tiny and live on machines with gigabytes of available memory.

The solution is again, fewer bigger scripts.

 

What we need from LL is much bigger textures, objects with more than 8 faces (eg 128 faces+) and much bigger scripts.

Li needs to factor in texture count and script count to reward.

 

It's easy to say LL needs to impose limits to keep creators making tight content, but really we have very tight limits already and getting around those limits is what causes the problems.

[ChinRey]

1 hour ago, Coffee Pancake said:

It's easy to say LL needs to impose limits to keep creators making tight content, but really we have very tight limits already and getting around those limits is what causes the problems.

We have tight limits in some ways and very laxed ones in other ways.

 

1 hour ago, Coffee Pancake said:

SL rendering uses an excessive number of draw calls, there isn't much we can do about this without extensive processing on the client to "gamify" SL assets.

I think it's fairly safe to ignore draw calls at this stage. LL is trying to switch to Vulkan and apparently Vulkan doesn't use OpenGL/DirectX style draw calls at all. I don't know how far they've come with this upgrade but since Apple have announced they will end their OpenGL support it won't be long before it's do or die for them and everybody else who want to maintain a cross platform graphics application.

 

1 hour ago, Coffee Pancake said:

I would very much like to see a bigger textures and more than 8 faces per mesh. Remember, it's not the size of the textures/meshes that's the problem, it's the number of textures/meshes.

I'm not really convinced there is much if anything to gain here.

When it comes to meshes, each face of a multiface mesh is treated as a separate submesh so it shouldn't matter much if they are uploaded as a single mesh or not. Judging by the download weight (I know that may not be too reliable) it seems several single face meshes actually tend to be more efficient than a single multiface one with exactly the same content.

As for textures, I once checked the cache size of a 1024x1024 texture and the same texture scaled down to 512x512 and it turned out the file size of the 512 actually was slightly less than a quarter of the 1024(!). Also it is plausible (although I can't say I really know much about this) that several smaller textures can load faster than a single big one since they can be downloaded in parallel. It's impossible to draw any kind of conclusion from this of course but it does show that we need more extensive tests and as far as I know, nobody has done that yet.

One thing is certain though. Introducing higher texture resolutions without upgrading the LI/weight control system first is a recipe for disaster. If the texture limit is increased to 4096x4096 and nothing else is changed, the trendy creator/merchant will replace the four 1024s on their navel piercing bestseller not with one 2048 but with four 4096s.

 

[Coffee Pancake]

6 hours ago, ChinRey said:

As for textures, I once checked the cache size of a 1024x1024 texture and the same texture scaled down to 512x512 and it turned out the file size of the 512 actually was slightly less than a quarter of the 1024(!). Also it is plausible (although I can't say I really know much about this) that several smaller textures can load faster than a single big one since they can be downloaded in parallel. It's impossible to draw any kind of conclusion from this of course but it does show that we need more extensive tests and as far as I know, nobody has done that yet.

A single big 1024 texture is far more efficient on the download, decoder and the render than 4x 512s.

A single 4096 would have about the same impact as a single 1024. Even bigger textures and we can leverage more cpu cores and actually get some benefit from that (right now the overhead incurred by leveraging more cores negates any savings, the data is just too small)

It's death by a thousand thousand tiny cuts.

We have done extensive testing and pulled the entire texture pipeline apart.

[ChinRey]

Good to hear you have tested it, I wasn't aware of that.

However:

1 hour ago, Coffee Pancake said:

A single 4096 would have about the same impact as a single 1024.

That is definitely not the case. I have tried using 2048x2048 textures in SL and there's a HUGE difference between one of those and a 1024x1024 both in load time and frame rate reduction. This was even in situations where the textures where cached and the overall texture load was more than low enough not to cause any VRAM shortage issues.

(For those who didn't know, yes there are a few 2048s and 4096s in SL. They were allowed for a short while and the textures that were uploaded then are still around.)

[Coffee Pancake]

2 hours ago, ChinRey said:

Good to hear you have tested it, I wasn't aware of that.

However:

That is definitely not the case.

It would be conditional on getting threaded decoding in play and the texture count being factored into Li, right now it's more overhead than it's worth and very situational in use. The viewer also makes no attempt to swap in lower resolution images as needed which would be required for 4K images.

If a texture, even a 4K one is impacting frame rate then something else is going on, massive texture atlases is a modern GPU's super power.

I would be very appreciative if you could drop any existing super rez images you have (or the UUIDs) on me in world

[ChinRey]

6 hours ago, Coffee Pancake said:

I would be very appreciative if you could drop any existing super rez images you have (or the UUIDs) on me in world

I actually still have the UUID of the one I used in my texture database. It's 80ddf7d3-3e26-bd60-0187-42bcaf8fa799

Turns out it's actually a 1024x2048 so only half the size of a straight 2048 - but still twice the size of a 1024. It's possible @Whirly Fizzle can help you locate some other and larger examples.

[Qie Niangao]

19 hours ago, Coffee Pancake said:

The best script optimization is using fewer scripts. It really doesn't matter what the scripts are doing, the number of scripts does (and NOT because more scripts use more memory).

Simple example. Say you have a scripted project that really needs about 256kb of total space to operate. You only get 64kb per script. But breaking this down into separate scripts with all the necessary house keeping code and code duplication means you probably need 6-8 scripts rather than 4. This isn't bad because your 6-8 script bundle now uses way more memory, it's bad because the combined processing over head has gone up by several factors.

But again - Memory is NOT the problem. Scripts are tiny and live on machines with gigabytes of available memory.

The solution is again, fewer bigger scripts.

Fewer scripts, yes. Bigger scripts? Only selectively. 

I'll wager that the majority of SL scripts will never execute an instruction more than a frame or two immediately after they've set their particular prim parameters, a frame or two after they're rezzed into the sim. That's why it would be a huge win to fix the scheduler so it doesn't effectively check those scripts every frame to see if they can run.

There are common scripts that need more than the 64KB Mono memory ceiling. Maybe the most common are animation engines, of which AVsitter is probably most popular now. We could discuss how it got to be the way it is and how it might be changed or replaced to better perform on current simulators, but of course that's not really the kind of "lag" this thread is about.

I would just add that, besides the scheduler, I think there's another underlying problem having to do with modularity, but I don't see such an easy improvement there. You can see it in AVsitter because there are a host of dumb little add-on modules that each perform some service not universally required of all use cases for the product. Problem is, the only way to make them available is in a whole separate script (and even then, some are only used once a fortnight or so). This is related to another problem, the proliferation of special-purpose scripts in commercial products: check how many attachments have both a resizer and a retexturizer (and maybe, god forbid, a "delete if unattached" hack). Each of those scripts may be the best in the world at doing the one thing they do, and they've achieved that by being super configurable to do every possible permutation of that thing, with every imaginable bell and whistle under every circumstance. The result is a whole host of unwieldy scripts that in any actual application exercise only a trivially narrow path through their code. Instead, nearly every attachment or piece of furniture could do everything they actually do using only a single script's worth of event handling, fitting comfortably in 64K, if only they didn't also need all the bloat that makes them work for other applications.

[Ardy Lay]

1 hour ago, Qie Niangao said:

Fewer scripts, yes. Bigger scripts? Only selectively. 

I'll wager that the majority of SL scripts will never execute an instruction more than a frame or two immediately after they've set their particular prim parameters, a frame or two after they're rezzed into the sim. That's why it would be a huge win to fix the scheduler so it doesn't effectively check those scripts every frame to see if they can run.

There are common scripts that need more than the 64KB Mono memory ceiling. Maybe the most common are animation engines, of which AVsitter is probably most popular now. We could discuss how it got to be the way it is and how it might be changed or replaced to better perform on current simulators, but of course that's not really the kind of "lag" this thread is about.

I would just add that, besides the scheduler, I think there's another underlying problem having to do with modularity, but I don't see such an easy improvement there. You can see it in AVsitter because there are a host of dumb little add-on modules that each perform some service not universally required of all use cases for the product. Problem is, the only way to make them available is in a whole separate script (and even then, some are only used once a fortnight or so). This is related to another problem, the proliferation of special-purpose scripts in commercial products: check how many attachments have both a resizer and a retexturizer (and maybe, god forbid, a "delete if unattached" hack). Each of those scripts may be the best in the world at doing the one thing they do, and they've achieved that by being super configurable to do every possible permutation of that thing, with every imaginable bell and whistle under every circumstance. The result is a whole host of unwieldy scripts that in any actual application exercise only a trivially narrow path through their code. Instead, nearly every attachment or piece of furniture could do everything they actually do using only a single script's worth of event handling, fitting comfortably in 64K, if only they didn't also need all the bloat that makes them work for other applications.

This is about how timeshare computing went with typical users.  Nobody really gave a damn how their job impacted other users on the system, as a result, much of the system's resources were devoted to resource management.  Today's solution is throw more computer at the job.  Hey, that scaled well, didn't it?

[Qie Niangao]

1 hour ago, Ardy Lay said:

This is about how timeshare computing went with typical users.  Nobody really gave a damn how their job impacted other users on the system, as a result, much of the system's resources were devoted to resource management.  Today's solution is throw more computer at the job.  Hey, that scaled well, didn't it?

Yeah, I'm sure the UNIX accounting system was a pig, although I never saw it in operation; same with VMS, MVS, TOPS-10, etc. What I do remember, though, was the ability to swap in little slices of programs or libraries on demand to keep a program's memory working set small enough to fit in the paltry address space of the hardware's word size. That would be mighty handy for AVsitter, for example, but instead each object scripted with that system will include scripts for features that are used very rarely, and each of those scripts must include all the functionality that feature could ever demand in any application. It's not only that all that stuff needs to be resident in sim memory—which is inefficient but memory is cheap—more importantly, those modules are all separate items on the sim scheduler, each adding a tiny bit of overhead 44 times a second for a function that may run monthly, and even then on the timescale of human dialog response instead of real time. There has to be a better way.

[Profaitchikenz Haiku]

57 minutes ago, Qie Niangao said:

What I do remember, though, was the ability to swap in little slices of programs or libraries on demand to keep a program's memory working set small enough to fit in the paltry address space of the hardware's word size.

This worked fine on systems like the PDP=11s, but once you got to the 32-bit processors there was almost no gain, sometimes even a los. On one project I was asked to see about implementing overlays on a VMS system, and the prototypes I set up found no measurable improvement, if anything, a slight loss with the time taken to swap the memory to and from disk.

Going back to an earlier point of yours, I worked my way through a lot of my scripts looking to see which ones did actually need the 64K maximum offered by mono, and I found very few did. Of those that didn't, almost all of them would fit in the 16K limit of LSL and so I have now stopped using mono for scripts where there is no possible requirement for it.

[Qie Niangao]

55 minutes ago, Profaitchikenz Haiku said:

... I worked my way through a lot of my scripts looking to see which ones did actually need the 64K maximum offered by mono, and I found very few did. Of those that didn't, almost all of them would fit in the 16K limit of LSL and so I have now stopped using mono for scripts where there is no possible requirement for it.

I don't think I'd recommend that change, generally. For one thing, Mono-compiled code executes much faster than the earlier "LSL" form.* Hence those non-Mono scripts may be burning (a lot) more CPU than they would otherwise. Note also that the below "dopey example" compiled in Mono runs in less memory than the 16KB required of each non-Mono script. (The 5KB limit is successfully set—although this script doesn't show that success—and anyway the limit doesn't need to be set for the script to stay well under 16KB when Mono-compiled.) Point is, Mono generally wins in both performance and memory (although a jam-packed 16KB non-Mono script will use more than 16KB when recompiled in Mono). One reason to avoid Mono, though, is when a small script is crossing region borders: It's quicker to blast a 16KB blob from one sim to another than to serialize and de-serialize even a trivially small Mono script state.

To the larger point: I'm not actually arguing for program memory overlays; memory is plentiful. Moreover, a unique Mono compilation unit will only load once in a sim even if it's used in many scripts, so memory is saved anyway. Rather, I'm fussing about how many dumb little scripts end up running in a region, partially because the script size limit prevents combining functionality into a larger script, and partially because functionality is delivered in script units instead of something like dynamic library functions to be invoked by a script as needed. (I'm not sure what the ideal program architecture really is for a platform like SL, but I'm pretty sure this isn't it—especially not when it's cloud-hosted and the most common scripts execute the least frequently.

____________________
* Try this dopey example with and without the Mono box checked:

string foobrify(integer i)
{
    string foo;
    integer i = 100;
    while (0 <= --i)
        foo += llGetSubString((string)i, -1, -1);
    return foo;
}

default
{
    state_entry()
    {
        llSetMemoryLimit(5120);
        string foo;
        integer i = 100;
        while (0 <= --i)
            foo = foobrify (i);
        llOwnerSay((string)llGetTime());
    }
}

 

[Profaitchikenz Haiku]

4 hours ago, Qie Niangao said:

I don't think I'd recommend that change, generally. For one thing, Mono-compiled code executes much faster than the earlier "LSL" form

I'd have to say here, does it always matter?

Take for example shoe or hair resizer scripts. You use them rarely, so if they take perhaps twice as long, it's insignificant really.

Poor example, I know, so let's take another one, a vehicle with some scripts in the child prims to set target omega for wheels, maybe animate a few textures. (let's for the moment ignore that a single script with setLinkPrimitiveParams will do the job in one script). Each of the small functions like targetomega or textureanimation are called infrequently, not looping constantly, so it doesn't matter if they run slightly slower, it's unlikely to be detectable. None of those functions requires any significant memory either.

The keynote here I'm trying to make is that it's the application of the script that really determines how to compile it, not just a desire to always attain the fastest possible runtime performance.

[Desiree Moonwinder]

On 10/2/2021 at 3:33 PM, Solar Legion said:

There is no legitimate reason - ever - to have your Draw Distance set that high. That is the size of four Regions.

When on my standalone SIM, I put my draw distance to 4096 so that I can build from top to bottom without bothering to move my avatar.  I do have a couple of spotter Alts that I stand near the points I'm building, so I can cam back and forth with radar. 

I have mainland experience and stitched-together region experience, and so I'm telling you from experience the only way to get performance in SL for combat and such is to have a single stand-alone region.  That's just the beginning of course.  You also have to keep inworld scripts low and meshes reasonable.