Feature Request - llLinksetDataMemoryFound() - A function the reports memory used by keys that match search pattern.
closed
Lucia Nightfire
This feature request is for the function llLinksetDataMemoryFound().
Uses the same input as llLinksetDataCountFound() but instead of returning the number of keys found, the total amount of bytes used by those key names, key values and protection is returned.
Log In
Spidey Linden
closed
Hello, and thank you for your feature request.
Incoming suggestions are reviewed in the order they are received by a team of Lindens with diverse areas of expertise. We consider a number of factors: Is this change possible? Will it increase lag? Will it break existing content? Is it likely that the number of residents using this feature will justify the time to develop it? This wiki page further describes the reasoning we use: Feature Requests
This particular suggestion, unfortunately, cannot be tackled at this time. However, we regularly review previously deferred suggestions when circumstances change or resources become available.
We are grateful for the time you took to submit this feature request. We hope that you are not discouraged from submitting others in the future. Many excellent ideas to improve Second Life come from you, our residents. We can’t do it alone.
Thank you for your continued commitment to Second Life.
Lucia Nightfire
I'm making another post to clarify the inputs and output of the proposed function, mostly because we can't seem to edit title or desc.
integer llLinksetDataMemoryFound(string pattern);
returns the amount of memory, in bytes, used by all keys that match pattern.
pattern is regex
Bugs Larnia
So I understand correctly: you would like a list of which key uses how much. That would be very interesting and useful data, yes.
Bleuhazenfurfle Resident
The one (slim) clear use-case I can see for this, is being able to account for protected entries. Please ensure the function works in that case — though that does technically leak information, a concerned script can work around it, and it's not anything making an object no-mod won't fix.
Lucia Nightfire
Bleuhazenfurfle Resident
In an environment with multiple types if expirable data, this would allow another means of "load balancing" and/or determining where to make cuts. It also allows statistical data analysis. It also allows user-defined memory allocation protocols. Lastly, it can be used as an alternative to hardcoding 131072 minus LSDDataAvailable to determine total data used in the event the cap is raised again.
I'm not sure what you mean by "leak information". Currently, LSDFind, LSDList, LSDCountFound and LSDDeleteFound will directly/indirectly tell you if protected keys exist as well as their names.
Bleuhazenfurfle Resident
Lucia Nightfire: Ahhh… Multiple types? Last time I looked, llLinksetXxx functions only store strings. If you mean the nature of the data being stored rather than it's "type", that and the rest of that big long paragraph are kinda obvious, yeah. This function will make it easier to keep LSD filled right to the tippy-top of it's limit…!
However, so long as the keys aren't protected (from the perspective of the running script), you can toss together a user function to do that easy enough — if rather a bit slower. That would make this function a mere "handy optimisation".
But, if this function can also correctly count protected keys, too, that's something a script can't already accomplish on it's own, and is far more worth making a built-in function for. If it can't, then I see no point to having it.
As for leaking information: often, protected keys are being protected because you don't want someone to be able to read their contents. Leaking information, means someone can gleam some information from them, despite being hidden — in this case, the strings length. But, I can't see many places where that could be an issue, and there's plenty ways to prevent it, so I mentioned it for completeness (and to make sure it at least gets consideration), but I think it's a non-issue overall.