Re: Doubts from leaks...

On Thursday, May 1, 2003, at 07:41  PM, Stefano Corsi wrote:

> Hi Dave,
>
> I've tracked down the memory leak to some moto_strdup that I used in
> motox_try_overloaded_[method|function]... from this experience I've 
> matured
> some doubts, that I'm gonna ask you about:
>
> MOTO_STRDUP
> ------------------
> I saw that often, in various files, you use moto_strdup without 
> freeing memory
> after use. So I had imagined that moto_strdup used a special *magic 
> system to
> track down allocated memory, without the need to free it. But then, in 
> a big
> nested loop, the use of a lot of moto_strdup created lots of problems. 
> So I'm
> unsure, now...

The shared heap memory allocated by moto_strdup gets recorded in an 
mpool which doesn't get freed until the end of page execution.

> PERFORMANCE (overloaded operators)
> -------------------
> I noticed that the below example:
>
> ${
>         int a;
>         for (a = 0; a < 100; a += 1) {
>                 int i;
>                 for (i = 0; i < 10000; i += 1) {
>                 }
>         }
> }$
>
> ran in 20 seconds (lots of time!) with moto_0_19_1 and in 40 seconds 
> (loads of
> time!!!) with my first version with overloaded operators on (you can 
> test on
> your machine and try to guess what poor processor I have!).
> I noticed that moto_strdup(s) in motox_try_overloaded... were much time
> consuming, so I changed the way operators are recognized with this 
> way, using
> simple ints in place of strdup(s):
>
Yes, shared heap allocation is the largest single factor in the 
performance of the moto interpreter (and most compiled moto 
applications). It should be avoided whenever possible :)

> /* operator name */
>     switch (op) {
>         case MATH_ADD:
>             opnum = 0; break;
>         case MATH_SUB:
>             opnum = 1; break;
>         case INC:
>         case POSTFIX_INC:
>         case PREFIX_INC:
>             opnum = 2; break;
>         case DEC:
>         case POSTFIX_DEC:
>         case PREFIX_DEC:
>             opnum = 3; break;
>         default:
>             opnum = 4;
>
> and I came down to 33 seconds. Again, loads of time (50% more that
> moto_0_19_1).
>
> Last, I tried to comment out the call for "moto_createMotonameForFn" in
> motox_lookupMethodOrFn and I came down to 25 seconds compared with the 
> 20 of
> moto_0_19_1. So I looked at moto_createMotonameForFn and it seems much 
> time
> consuming, with the buffer and everything. I wonder if we should study 
> some
> faster way to lookup function names, or maybe a cache system for 
> overloaded
> operators.
>
> THIS HURTS! THIS HURTS! THIS HURTS! THIS HURTS!
> PERFORMANCE (compared with php)

If we wanted to be really naughty we could associate a function with a 
unioncell in motov and use that association in motoi :) The biggest 
(and likely quickest) gain would come from getting rid of the strdup 
though. Maybe we should pass a character array (256 characters or so 
should do it) to moto_createMotonameForFn that it can construct the 
function/method name in. That array would be stack memory speeding 
things up considerably (as well as freeing up memory right away).

> -------------------
> However, the time needed to execute the loop, even with moto_0_19_1, 
> seemed
> too much to me. So I created a similar php script:
>
> <?
>         for ($a = 0; $a < 100; $a += 1) {
>                 for ($i = 0; $i < 10000; $i += 1) {
>                 }
>         }
> ?>
>
> that executes in 1.26 second, more or less.
>
PHP's interpreter is much more optimized than moto's. In the ideal 
world the moto interpreter would never allocate heap memory that the 
page it was executing did not explicitly ask for. Instead of 
concentrating on interpreter performance however (since the addition of 
motoval, frame, and buffer pools) I've attempted to try and keep it 
clear and easy to understand since I view the interpreter as really 
only for application development.

> BIG RELIEF! BIG RELIEF! BIG RELIEFS! BIG RELIEF!
> PERFORMANCE (in compiled mode)
> -------------------
> The compiled version in moto, of course, executes in 0.01 seconds and 
> this was
> expected.
>
> What I wonder is: I know that we can compile and achive the speed of 
> light,
> but is it expected that we have a 1 <--> 20 disadvantage with php in
> interpreted mode on a simple nested loop?

There are many ways we could optimize the interpreter in its current 
form, however I suggest we wait a bit (till the rest of the substantive 
language changes are done), before we attempt major changes there. 
Optimal interpreters have a quite different structure than motoi.

> Or maybe it is acceptable because moto must be seen as a two mode 
> language and
> the interpreted mode is only for prototyping or pages without complex
> calculations?

> Or am I doing something very very wrong?
>
Nope, you're right on the money :) The optimizations I've done to motoi 
in the past have usually come about because a moto app I was writing 
was taking to long for the pages to execute in development ... so I'd 
go in and speed up the interpreter ... then I'd add more to the moto 
app slowing it down ... forcing me to go and speed up the interpreter 
again :)

-Dave

> Stefano
>
>
>