Tels wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Moin,
Jim Cromie <[EMAIL PROTECTED]> wrote:
attached is an almost-there patch which:
replaces most arena-root pointers with an array of them
replaces same root pointers with array.
simplifies several macros using them.
the line-count doesnt shrink much, but it simplifies source code, and
shrinks object code:
I didn't understand this comparisation fully. Are this bytes used by the
functions?
(I was brief here, cuz Ive posted on this topic b4, w/o any response)
bytes ? assuming you meant pointers, heres some elaboration.
(theres lots of good commentary in sv.c)
most of the body types are allocated from arenas rather than from malloc,
to avoid malloc overhead, and to be able to report un-reclaimed vars during
final cleanup.
when theyre needed, the arenas are added to the front of the chain pointed
to by ~14 separate/discrete (and typed) pointers, all of which are part of
the interpreter structure. The 14 different types leads to lots of
macro ##
convolutions (which is an improvement over the previous cut-paste
duplication),
and large switches full of closely related code.
replacing the typed pointers with an array of void pointers, and
adding a couple of svtype indexed lookups makes it possible to
simplify and/or strip some of the macros.
Only some of that cleanup is done thus far.
Anyway, this work sounds good. Just one small detail:
+
+ for (i=0; i<17; i++) {
+ S_free_arena(aTHX_ (void**) PL_body_arenaroots[i]);
+ PL_body_arenaroots[i] = 0;
+ PL_body_roots[i] = 0;
+ }
The 17 should be defined somewhere. It might change someday :)
true. never say never - but it hasnt been touched since 5.00503.
If it changed, B.xs would break too, theres a hard-coded correspondence
between
the svtype and svclassnames. A svtype_info struct could solve that,
but would add some (minor) overhead. (svclassnames isnt in sv.h to
avoid just that)
+ Note that 1st 4 sv-types have no bodies,
+ *_allocated bodies are smaller cuz they have unused slots.
+*/
I do not like the abbrevitation "cuz". I sometimes use "w/" and "w/o", but
u dont ? :-P ok fair enough.
I'll wait a while, perhaps others will offer feedback.
Im happy to add minor tweaks as a pre/post-condition to application ;-)
the former is already borderline for me. I think you have the time to
spell comments out. Otherwise we will see comments like this one next:
/* 4 u we r ! d0ing teh all0cat'n */
:-D
Best wishes,
Tels
thanks
jimc
