Fine, don't waste your time responding. Go do better things.
On Thu, Mar 11, 2010 at 6:39 AM, Carlo Wood wrote:
> It makes little sense to me to put time into convincing a random non-Linden.
> And since LL is going to ignore the whole discussion/idea anyway, I have
> better things to do. Sorry.
It makes little sense to me to put time into convincing a random non-Linden.
And since LL is going to ignore the whole discussion/idea anyway, I have
better things to do. Sorry.
On Wed, Mar 10, 2010 at 11:56:36AM -0500, Lear Cale wrote:
> If it were a simple change, I'm sure it would be considered
If it were a simple change, I'm sure it would be considered. What
you're suggesting sounds like would require a massive rewrite. I
agree that a dynamic system would be much better, easier to code and
less wasted memory. But without detailed knowledge of how the system
is currently implemented, i
Most scripts allocate space (add items to lists) based on events. How
would the number of events be estimated?
Seriously, this requires more than an oracle. It requires
clairvoyance. Unless the coder specically codes a limit on the number
of list elements added, there is no way to predict.
Lear
Am 09.03.2010 um 23:57 schrieb Michael Schlenker:
>
> Am 09.03.2010 um 02:54 schrieb Lear Cale:
>
>> huh? Can you point to existing technology for this analyzer? Seems
>> to me like it would require an oracle.
For an example of such a technique for Java bytecodes:
http://citeseerx.ist.psu.ed
Am 09.03.2010 um 02:54 schrieb Lear Cale:
> huh? Can you point to existing technology for this analyzer? Seems
> to me like it would require an oracle.
It might require an oracle to reach 100%, but if you go for the easy part, its
not that hard (assuming a sane GC). LSL is a pretty simple lan
onecutter
> Sent: Tuesday, March 09, 2010 9:06 AM
> To: Carlo Wood
> Cc: server-b...@lists.secondlife.com; opensource-dev@lists.secondlife.com
> Subject: Re: [opensource-dev] Script Memory Management Algorithm
>
> On 2010-03-09, at 07:26, Carlo Wood wrote:
> > This is exactly the kind of rea
.secondlife.com] On Behalf Of Argent
Stonecutter
Sent: Tuesday, March 09, 2010 9:06 AM
To: Carlo Wood
Cc: server-b...@lists.secondlife.com; opensource-dev@lists.secondlife.com
Subject: Re: [opensource-dev] Script Memory Management Algorithm
On 2010-03-09, at 07:26, Carlo Wood wrote:
> This is e
On 2010-03-09, at 07:26, Carlo Wood wrote:
> This is exactly the kind of reaction that drives me away from here.
>
> I propose a simple way get FOUR times the memory for all the
> scripts, at
> no other cost than adding some malloc code to your mono engine.
I don't think you have established tha
Carlo +1.
Explicit pre-allocation of memory by users has to be one of the silliest and
most regressive "improvements" appearing in SL for a long time. It's a
waste of memory, it takes us back decades, and it's a burden on users.
So why do it?
"Because we've decided to, full stop." -- seems to b
This is exactly the kind of reaction that drives me away from here.
I propose a simple way get FOUR times the memory for all the scripts, at
no other cost than adding some malloc code to your mono engine.
And you simply say, "This is what we ARE doing, we're not going to change that".
Why this i
I'm naive here, I don't know the server side of it. But how can a sim
know when a script hits a threshold, and not be able to report the
actual memory used ? Since it can check it against a threshold...
On 8 mars 2010, at 18:46, Kelly Linden wrote:
We are not out to write a new malloc for
Please tell me how to register for this list. I was registered for
sldev, but don't remember how.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep un
huh? Can you point to existing technology for this analyzer? Seems
to me like it would require an oracle.
On Mon, Mar 8, 2010 at 2:03 PM, Michael Schlenker
wrote:
>
> Am 08.03.2010 um 18:46 schrieb Kelly Linden:
>
>> We are not out to write a new malloc for mono. What we have is a system
>>
Am 08.03.2010 um 18:46 schrieb Kelly Linden:
> We are not out to write a new malloc for mono. What we have is a system that
> throws an exception when the memory used by the script hits a certain
> threshold (64k currently). This exception is caught so we can "crash" the
> script. The futur
We are not out to write a new malloc for mono. What we have is a system
that throws an exception when the memory used by the script hits a certain
threshold (64k currently). This exception is caught so we can "crash" the
script. The future small scripts and big scripts projects will add new
func
On 2010-03-07, at 07:50, Carlo Wood wrote:
> Lets assume that the *average* script uses
> 8 to 16 kB of real memory. LL's design allocates
> 64 kB regardless, leading to an overhead of
> 400 to 800% (meaning they need to buy 5 to
> 9 times the memory that is theoretically needed).
This is not the
Lets assume that the *average* script uses
8 to 16 kB of real memory. LL's design allocates
64 kB regardless, leading to an overhead of
400 to 800% (meaning they need to buy 5 to
9 times the memory that is theoretically needed).
In that light, I gave it some more thought, and
think something as co
18 matches
Mail list logo