httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Kluft <ikl...@cisco.com>
Subject Re: [2.0] API extension mechanism (updated proposal)
Date Sat, 03 May 1997 12:34:59 GMT
> From: Dean Gaudet <dgaudet@arctic.org>
> On Fri, 2 May 1997, Ian Kluft wrote:
> >    http://www.employees.org/~ikluft/apache/api2.0.html
> 
> People will still be able to build a binary distribution (such as
> Stronghold) that will allow people to compile and link in their own
> modules, right?  It looks like this is possible provided people don't want
> to change the api-config. 

Yes.  Actually, since apigen takes any number of files for input, there
could be more stuff coming from other files... generated by future versions
of the Configure script, or from a separate site-local class definition file.

> <http://www.arctic.org/~dgaudet/patches/apache-1.2-run_method-performance.patch>

I get a "Forbidden" error trying to read the URL.  I'll try responding to
the next paragraph after I can take a look at it...

> I'm seeing a noticeable gain from this patch -- run_method down from 7 us
> per call to 1 us per call (6.7% cpu time to .91% cpu time).  run_method is
> called at least 7 times per hit, and something like 10 times per hit on
> negotiated content.  How easy is a similar optimization going to be? 
>[...] 

> It's quite late so I might have this next part all wrong, I think there's
> far more that can be computed at compile time using the preprocessor.
> For example we can use preprocessor tricks to get us properly casted

I like these ideas.  Well done.  Thanks for the time you took to look
it over!

> Consider class lookup, and assume we know we're invoking a method on an
> object of class lookup.  After all, in the lookup case itself we should
> know that we've go an object that inherits lookup...  That would be
> something that's decided on during server configuration.  So it sucks to
> pay for the binary search all the time (and the extra function invocation,
> and the va_args manipulation, and lose the ability to have leaf functions
> omit-frame-pointer...).

The va_args was a relic from the algorithm I listed in my 1991 thesis that
used a similar algorithm.  After I posted this here, the value of va_args
hasn't sat well with me either.  (It was fine in an academic environment
6 years ago.)  I've been trying to think of some alternatives that are
1) less expensive and 2) callable from other-language interfaces like
mod_perl.

For the dynamic api_run() calls, the leading alternatives I'm thinking of
right now are either array_header's or just a plain array of parameters.

> I'm thinking of something along these lines.
> 
> #define api_run_static(object,class_name,method_name)		\
> 	(*(cast_##class_name##_##method_name)			\
> 	    ((object)->class->method_tbl[			\
> 		api_static_method_##class_name##_##method_name].func))
> 
> /* function prototypes for class lookup */
> #define cast_lookup_dump	(void (*)(dump prototype))
> #define cast_lookup_init	(void (*)(init prototype))
> ...
> #define cast_lookup_get	(char *(*)(request_rec *r, const char *key))
> ...
> 
> /* indicies into api_class_lookup__methods */
> enum {
>         api_static_method_lookup_init,
>         api_static_method_lookup_create_dir_config,
>         api_static_method_lookup_merge_dir_config,
>         api_static_method_lookup_create_server_config,
>         api_static_method_lookup_merge_server_config,
>         api_static_method_lookup_open,
>         api_static_method_lookup_close,
>         api_static_method_lookup_get,
>         api_static_method_lookup_put
> };
> 
> Then invoke api_run_static(foobar,lookup,get)(r, key).

That sounds like a project for this weekend... ;-)  This definitely would
make the whole concept more useful.

Something that will still need more "think time" is how to handle dynamic
and static calls for the same objects.  We may have the separate which
functions can be accessed dynamically or statically - but I don't want to
give up and resort to that yet.  It would be *very* nice to be able to do
both.  But it's almost surely going to impose some sort of restrictions
on the parameters that can be passed through the Object API.

> To do (single) inheritance we just ensure that the parent class' methods
> are listed first, and in the same order in the child class.

The methods are not necessarily listed in inheritance order.  That happenned
coincidentally from the way my example classes were set up.  The methods are
sorted in numerical order of the method ID, so that the binary search is
possible (guaranteeing the search cost won't exceed O(log n) at run time.)

> Ack, it's still expensive.

There's no doubt that adding OO features is not free.  The kind of discussion
we're holding now is good because it'll keep the OO-based costs down.  But
this Object API (or anything OO-related) is only appropriate for parts that
need it, such as the server API and new extensions to the API... where all
the separate parts come together.

I wouldn't recommend re-fitting the entire core to use the Object API (or any
dynamic OO setup) because of the overhead from function calls, searches, etc.
Although OO design could still benefit some other parts that can't use this.
-- 
Ian Kluft  KO6YQ PP-ASEL                                  Cisco Systems, Inc.
ikluft@cisco.com (work)  ikluft@thunder.sbay.org (home)          San Jose, CA

Mime
View raw message