Rebol Memory Allocation Strategy?

Did you mean for the 'str in the function to be global? If so, then there's no need for the object, as you could just create 'str outside of the function. ie... str: make string! 8192 my-f: func[][ clear str ; etc... ] Not sure what happens when it's local to the function though. -- Carl Read

As far as I know you're right. A few additions, though ... my-obj: make object![ ; untested code str: make string! 8192 set 'my-f func[][ clear str ; appends much data to string... ] ; end function ] ;end object this way you can just use 'my-f, without having to think about the object! (no my-object/my-f needed). _or_ you could use my-f: func[/local str][ str: "" clear str ; appends much data to string... ] ; end function 'str being a literal string, it will be retained over function invocation. Of course the first usage of the func might be slow, because 'str would have to slowly grow, while being appended to. _or_ you use the ideas someone else woll surely come up with. Kind regards, Ingo

I actually am using strategies like this, but it is nice having a supporting second opinion.... Thanks Ingo! -tj-

-- Tim Johnson <[tim--johnsons-web--com]> http://www.alaska-internet-solutions.com http://www.johnsons-web.com

of my-obj? Usually, one wants the string value for use in other things. So the first function: my-f: func[][ str: make string! 8192 ; untested code ; appends much data to str.... return str ] is better if one wants to use the value returned by evaluationg 'my-f multiple times in the same 'compose. Otherwise you'll end up with the same value repeated several times. For example:

== "95"

== "52"

== "80"

== "96"

== "67"

== ["12" "12" "12"]

== ["71" "71" "71"] And now with new string! value each time:

== ["32" "67" "30"]

== ["57" "86" "35"] I hope that helps! Andrew Martin ICQ: 26227169 http://valley.150m.com/

I'm hardly an expert on anything. I wrote some little scripts just for fun, testing memory useage and speed. First script rerequests a string within the function. memory usage fluctuates a bit but adds a fair bit of time with numerous iterations: ;#######First script t: now/time/precise reform [to-integer system/stats / 1024 "KB"] my-f: func[][ str: make string! 8192 loop 20000 [append str "akslkjslkjslskjlsj"] print reform [to-integer system/stats / 1024 "KB"] ] loop 100 [my-f] print now/time/precise - t ;####### Second script only sets up the string once, memory usage remains essentially flat, and it is four times faster than the first. ;########second script t: now/time/precise reform [to-integer system/stats / 1024 "KB"] str: make string! 8192 my-f: func[][ clear str loop 20000 [append str "akslkjslkjslskjlsj"] print reform [to-integer system/stats / 1024 "KB"] ] loop 100 [my-f] print now/time/precise - t ;######## These scripts probably mean little, but they confirm the idea that it is probably better to do less make-ing and more clear-ing. Maybe a real pro can comment using my feeble scripts. :-) Hope this doesn't muddy the waters further. --Scott Jones

The comments made by Scott and Ingo seem in step with my own point of view, *but* I'd like to see Andrew step in here. I've been learning to work with Andrew's ML dialect and my question was prompted by Andrew's use of memory in his 'ML function. From the previous entry that Andrew made regarding this thread, I believe that 'compose makes a difference in this strategy. Andrew is deeply informed of rebol and I believe that his approach is well thought, I'm just not yet understanding it (yet). So hopefully Andrew is reading this and will comment further. -tim-

-- Tim Johnson <[tim--johnsons-web--com]> http://www.alaska-internet-solutions.com http://www.johnsons-web.com

== ["95" "52" "80"]

== ["32" "32" "32"] Andrew Martin ICQ: 26227169 http://valley.150m.com/

IMHO "better" is a function of many things, so I prefer to use more descriptive terms most of the time, especially in cases where there are significant trade-offs. Allocating a fresh string each time is more secure, as it reduces the chances of inadvertent coupling. For example, in: a: func-returning-string-ref b: func-returning-string-ref append a "foo" if the function returns a reference to the same string (CLEARed or not), then the last expression also mutates the value of B. This *might* be what the programmer intended, but if not, it is a very fertile source of subtle bugs. IIRC, the "classic" C implementation of date formatting used a single internal buffer for the result, returning a pointer to that same buffer on every use. This was almost universally reviled as a source of needless bugs and confusion. Re-using the same string (possibly with clearing) certainly has the advantage of speed, but one must make *sure* that there's not any possibility that references from a prior evaluation are still hanging around with the expectation that their former value(s) will persist. IMHO this is a stellar example of how tweaking a lower-level bit of code for some presumably noble purpose can end up making life much more complex for later, higher-level uses of said code. I suggest that the author of a function should almost always try to maximize simplicity of use for the caller, even at the expence of making his/her own life more difficult. Complexity resembles entropy in this regard; it's much easier to open a can of worms than it is to re-can them! -jn- -- ; Joel Neely joeldotneelyatfedexdotcom REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] { | e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]

Good point, and I was particularly sloppy in my wrap-up.

Excellent reminder. I always feel a bit silly putting an absurd number of iterations into an arbitrary example. I do it mainly to understand the relative cost of operations. I hope I am not mis-casting what you have said, but you are reminding me that there are costs in other areas besides speed and memory use alone. Good point, because this is exactly why I have gravitated toward scripting languages. ...

Another Joel quotable. Your clarity of thought and skills of articulation continually amaze me. Thanks for your continued contributions to the list! --Scott Jones