Difference between revisions of "Talk:LlSetMemoryLimit"
Jump to navigation
Jump to search
m |
|||
(One intermediate revision by one other user not shown) | |||
Line 2: | Line 2: | ||
Agreed! Mono bytecode is too fat for such applications. -- [[User:Michelle Resistance|Michelle Resistance]] 22:15, 25 September 2011 (PDT) | Agreed! Mono bytecode is too fat for such applications. -- [[User:Michelle Resistance|Michelle Resistance]] 22:15, 25 September 2011 (PDT) | ||
:I was initially inclined to disagree but a look at my notes on LSO indicate otherwise. 1k would be enough for quite a lot. Naturally you would have to drop any e event that was going to max out it's memory. -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 18:51, 26 September 2011 (PDT) | |||
::Would it necessarily require a restart? I'm probably wrong, but when an event isn't running there shouldn't be a stack, so the memory reclamation could be attempted at that point, by just discarding any empty memory at the end. Basically the function would look to see if there looks like there's enough memory to discard to meet the target, if there is then it returns <code>TRUE</code> and when the current event finishes it chops away, otherwise it returns <code>FALSE</code> and doesn't bother. Defragmentation on LSO scripts would still be nice, but and should be doable on a similar principle (wait till the event finishes since it'll be easier to do then). | |||
::I dunno about working within 1kb or less, maybe for very simple interactive items like animators (though that's why I posted {{JiraIssue|SCR-369}} =), but I'd say a majority of my LSL scripts could manage limits between 4kb or 8kb; it's the kind of thing that could add up. If an LSL script gets more complex than that then I almost always have to switch to Mono for the speed or to avoid the risk of stack/heap collisions if it receives too much data from chat or whatever. It'd be interesting if LSL scripts can be analysed grid-wide, as LSO scripts that don't use lists, or only work with strings from well known sources (e.g - avatar names) wouldn't be too hard to detect, especially from source, and could potentially have retroactive limits; easily way more effort than it's worth, but I'd love to see what the results of that could be, as I think the vast majority of scripts out there are actually pretty simple.<br/>-- '''[[User:Haravikk_Mistral|Haravikk]]''' <sup><small>([[User_talk:Haravikk_Mistral|talk]]|[[Special:Contributions/Haravikk_Mistral|contribs]])</small></sup> 13:22, 15 September 2012 (PDT) |
Latest revision as of 12:22, 15 September 2012
I would love to be able to call llSetMemoryLimits on an LSO script, even if it caused a script restart (which it probably would). Given the relatively compact nature of LSO, I bet you could do a lot of useful stuff in 1k or less. -- Argent Stonecutter 01:07, 10 August 2011 (PDT)
Agreed! Mono bytecode is too fat for such applications. -- Michelle Resistance 22:15, 25 September 2011 (PDT)
- I was initially inclined to disagree but a look at my notes on LSO indicate otherwise. 1k would be enough for quite a lot. Naturally you would have to drop any e event that was going to max out it's memory. -- Strife (talk|contribs) 18:51, 26 September 2011 (PDT)
- Would it necessarily require a restart? I'm probably wrong, but when an event isn't running there shouldn't be a stack, so the memory reclamation could be attempted at that point, by just discarding any empty memory at the end. Basically the function would look to see if there looks like there's enough memory to discard to meet the target, if there is then it returns
TRUE
and when the current event finishes it chops away, otherwise it returnsFALSE
and doesn't bother. Defragmentation on LSO scripts would still be nice, but and should be doable on a similar principle (wait till the event finishes since it'll be easier to do then). - I dunno about working within 1kb or less, maybe for very simple interactive items like animators (though that's why I posted SCR-369 =), but I'd say a majority of my LSL scripts could manage limits between 4kb or 8kb; it's the kind of thing that could add up. If an LSL script gets more complex than that then I almost always have to switch to Mono for the speed or to avoid the risk of stack/heap collisions if it receives too much data from chat or whatever. It'd be interesting if LSL scripts can be analysed grid-wide, as LSO scripts that don't use lists, or only work with strings from well known sources (e.g - avatar names) wouldn't be too hard to detect, especially from source, and could potentially have retroactive limits; easily way more effort than it's worth, but I'd love to see what the results of that could be, as I think the vast majority of scripts out there are actually pretty simple.
-- Haravikk (talk|contribs) 13:22, 15 September 2012 (PDT)
- Would it necessarily require a restart? I'm probably wrong, but when an event isn't running there shouldn't be a stack, so the memory reclamation could be attempted at that point, by just discarding any empty memory at the end. Basically the function would look to see if there looks like there's enough memory to discard to meet the target, if there is then it returns