I think "large" is dependent on context.
I've used LSON files larger than 100 MB, but I don't know that I would
recommend that for all possible use cases.
The bug DB link in this post suggests that size of a given array isn't
necessarily a problem or not a problem, it all depends on what
spe
Do we have a ballpark idea of what "large" might be? Is it more like a
gigabyte or a few hundred megabytes or...? I know it will be variable
and depend on other factors, but it would be nice to have a general idea.
On 9/26/19 11:12 PM, Dar Scott Consulting via use-livecode wrote:
I don't think
I don't think that is large. If you are processing data the same size and
somehow leaving the previous data around, that might build up. That might build
up in queues and stacks, in a message storm and in appended data. But, I am
guessing that that is not likely.
> On Sep 26, 2019, at 1:54 PM,
Tom Glod wrote:
> Hi folks, I'm wondering if anyone can help me to understand
> Livecode's garbage collection. I am developing an application that
> is intended to stay in memory and so I must watch memory consumption
> carefully. I've had some instances where memory ran way out of
> control...
2.5 mb is not big at all. please remember to test with 9.05 when
worried about leaks.
On Thu, Sep 26, 2019 at 3:55 PM J. Landman Gay via use-livecode <
use-livecode@lists.runrev.com> wrote:
> On 9/24/19 2:39 PM, Dar Scott Consulting via use-livecode wrote:
> > Sources of memory leaks are LC,
On 9/24/19 2:39 PM, Dar Scott Consulting via use-livecode wrote:
Sources of memory leaks are LC, LC scripts, OS, libraries, LCB and (I suppose)
compilers. I don't think we can assume the problem is not in the user script. I
have seen script memory leaks like these:
1. Leaving large data in scri
Dar, you bring up some good points here thanks. i've been burned by that
before.
I do want to mention that I reported a bug a while back where not all
messages were sent while wait with messages. panos seemed to have
confirmed that problem, but it hasn't moved since.
Maybe that part of the prob
Yeah, "GUI recursion" is a little obtuse.
I'm referring to a style of using wait with messages inside an event handler so
that other events (especially keyboard and mouse) can be handled. Sometimes
this is done to allow a "background" task. It is easy to do this in a way that
makes a mess of th
HH...yup I know.. Dar, thanks for those hints and tidbits, I'll be
putting those right into my pocket as i optimize code going forward.
I have pretty good cleanup habits, so I am getting good results with how
it is (in 9.05) . but sometimes its scary. It like the GC happens only
when thi
I don't know where you will find details. (Maybe if we keep this conversation
going, we will get a response in a half day.)
I believe it is reference-counting with lazy cleanup for high-level objects,
but with carefully crafted destructors for low level objects. Because of the
lazy cleanup, it
LC 9.0.5 closed at about 42 memory leaks ...
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Hi folks, I'm wondering if anyone can help me to understand Livecode's
garbage collection. I am developing an application that is intended to
stay in memory and so I must watch memory consumption carefully. I've had
some instances where memory ran way out of control but I found a couple
of re
12 matches
Mail list logo
