On 6/12/20 4:12 PM, jr wrote:
...
>> (1) - IIRC memory use is higher with the newer features. Both because
>> mixed array elements are all of a size which accommodates the largest.
>> And on growth the increments are in some sort of multiple of the
>> existing size. Again, not familiar with the code and I have not myself
>> used it. All Christoph's work.
> 
> both mixed arrays and dynamic arrays are used, together.
> 
> (will 'clipka' be able to chip in, at some point?  (I must have missed what
> happened))

Don't know. Time will tell. Communication stopped over a year ago as you 
know.

> 
>> (2) - Undefs are are not going to help with memory fragmentation over
>> time in any case supposing you are allocating and freeing a large number
>> of varying arrays.
> 
> had not considered fragmentation.  how does it work, POV-Ray allocates all in
> advance and doles out, or allocates on demand?  with relatively large arrays
> being created/overwriting an existing, is there a rule of thumb for estimating
> memory consumption[*]?
> 
> [*] another thing missing completely in the documentation.

I thought fragmentation was probably your first concern when you 
mentioned garbage collection :-). Garbage collection in terms of 'stop 
and do it sometimes' isn't really a POV-Ray SDL / c++ thing.

The code allocates and frees as needed. Memory management is left to 
libc's malloc et al. Perhaps possible to do better here - jemalloc? Way, 
way down on my to-play-with list though.

Some rules of thumb for memory consumption have been described in the 
newsgroups over time - Christoph's efforts mostly - but nothing in the 
documentation. Such documentation is not easy to keep current. Updates 
in povr have already changed things in quite a few places.

Aside: On some level I wonder why undef exists... A long time ago when 
memory was precious I can see reason's to make it available to users so 
things in include files, for example, could be freed early - while 
parsing rather than at post parsing. Today, I'm playing with the idea of 
dumping the keyword. It would push us a smidgen more in the functional 
language direction - which for a scene description language I think a 
good thing. With respect to dynamically executing functions via pointers 
within inbuilt functions, not having the keyword would make things 
simpler.

> 
> (will 'povr' provide at least some introspection tools?)
> 

Nothing planned short term. A wild idea on which I spent a little time 
late last year and early this, is replacing much of the internal povr 
backbone code with Redis. It would enable considerable introspection - 
while enabling better shape/functional code flow for performance. But 
yeah, someday, maybe.

Remembering now, shortly into my first real job, being pulled aside by 
an older co-worker after a meeting. A meeting in which I'd been asked 
how long it would take me to do a task. I'd blurted out two hours. He 
said, "You don't believe it now, but whenever answering how long will it 
take questions with respect to technical issues, always bump your first 
thought up to the next work-time increment and multiply by two. Two 
hours -> day * 2 -> two days. Not sure how he came up with this formula, 
but pushing 40 years later it's been remarkably accurate. This rule of 
thumb in mind - it doesn't bode well for the Redis idea... :-)

Bill P.

Post a reply to this message