List Commands Library for 50g

[snrowe]

(09-23-2017 08:26 PM)DavidM Wrote:  Hey Scott -

My earlier comments were about a specific technique that saves a list to USEROB so that its exploded elements don't bog down GCs that occur while processing. Unfortunately, I haven't been able to nail down an effective way to do that such that a list which starts out in TEMPOB is freed up during the processing phase of the command -- the O/S keeps an active reference to the TEMPOB version so that it can't be freed during a GC, thus taking up twice the space that is actually needed.

I only recall a little bit about the program you were working on, but isn't the bulk of your data in the form of strings? I'm wondering if you could avoid some of this by keeping your string data separate from other data you might want to save in a list. It's still likely that a copy of the string would have to be made each time you manipulate it, but GCs shouldn't be as much of a problem as they can be with lists. Would it be possible for you to combine multiple strings into a single string object by inserting separation characters?

Hi David,
Sounded like a similar problem to what I was having. Not sure if below applies to your issue but will include incase it does.

When researching how to free up memory when manipulating large lists I learned the following. When you extract even one element from a list that has not been stored to a variable it keeps the entire list in memory as long as the extracted element is on the stack. I also found reference that Matrices/Vectors were more memory efficient for calculations if using numbers. (ref William Wicks 'HP48 Insights PART I: PRINCIPLES AND PROGRAMING' Section 11.6 Composite Objects and Memory').

On my program, yes that's exactly the problem I found each time I modified the list a copy of string I was tying to modify was being created. Could not find a way around this with USERRPL. Think I did what you're suggesting, now I store string messages as there own variables in a MESSAGE directory also limited the length to 300 characters and created searching tools to pull together messages with certain criteria. Was hoping there might be a way to explode a list into individual elements while destroying the original list so it's not taking up memory while your exploding it.