David Hakim
2003-05-01 23:47:01 UTC
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
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 anI'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
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...
mpool which doesn't get freed until the end of page execution.
PERFORMANCE (overloaded operators)
-------------------
${
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
Yes, shared heap allocation is the largest single factor in the-------------------
${
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
performance of the moto interpreter (and most compiled moto
applications). It should be avoided whenever possible :)
/* operator name */
switch (op) {
opnum = 0; break;
opnum = 1; break;
opnum = 2; break;
opnum = 3; break;
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 aswitch (op) {
opnum = 0; break;
opnum = 1; break;
opnum = 2; break;
opnum = 3; break;
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)
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
<?
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 idealHowever, the time needed to execute the loop, even with moto_0_19_1,
seemed
<?
for ($a = 0; $a < 100; $a += 1) {
for ($i = 0; $i < 10000; $i += 1) {
}
}
?>
that executes in 1.26 second, more or less.
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 currentPERFORMANCE (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?
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 motoilanguage and
the interpreted mode is only for prototyping or pages without complex
calculations?
Or am I doing something very very wrong?
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