tomcat-taglibs-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chen, Gin" <>
Subject RE: Speed differences between <jsp:include> and <c:import>
Date Wed, 24 Sep 2003 15:25:26 GMT
Ah I c.. The code that ur interested in:

If you look at the code for ImportSupport you'll see Shawn's comments:

    // Actual URL importation logic

     * Overall strategy:  we have two entry points, acquireString() and
     * acquireReader().  The latter passes data through unbuffered if
     * possible (but note that it is not always possible -- specifically
     * for cases where we must use the RequestDispatcher.  The remaining
     * methods handle the common.core logic of loading either a URL or a
     * resource.
     * We consider the 'natural' form of absolute URLs to be Readers and
     * relative URLs to be Strings.  Thus, to avoid doing extra work,
     * acquireString() and acquireReader() delegate to one another as
     * appropriate.  (Perhaps I could have spelled things out more clearly,
     * but I thought this implementation was instructive, not to mention
     * somewhat cute...)

You can follow the aquireXXX methods to see the implementation.

-----Original Message-----
From: Sgarlata Matt [] 
Sent: Wednesday, September 24, 2003 10:56 AM
To: Tag Libraries Users List
Subject: Re: Speed differences between <jsp:include> and <c:import>

Well we have three different include methods (4 if you count tiles:insert)
and I'm just trying to fully understand the implications of using each.

<%@ include file="" %> is like a C include, so it leads to larger JSP files,
but it offers a speed advantage over passing along the request, which is
what <jsp:include> does.

I was thinking that a naive implementation of <c:import> might just
construct the URL and go fetch from the Internet every time, even if the URL
was on the local machine.  This would mean getting the content through the
local web server rather than the local file system.  This is a toy example,
but I'm thinking that since <jsp:include> has been around longer that it
might have been tuned better than <c:import> and thus could be depended on
to be faster than <c:import> for nearly all containers.  Does that make

Also, since you can store <c:import> in a variable I'm wondering if
<c:import> might do some type of full read before printing to output,
whereas I imagine <jsp:include> uses buffering.  This could show a
performance difference for very large files, with <c:import> requiring
longer and taking more memory to get all the data in the import whereas
<jsp:include> did things with buffers.  Am I thinking about this too much?
I really don't know how all this stuff is implemented ;)

----- Original Message ----- 
From: "Chen, Gin" <>
To: "'Tag Libraries Users List'" <>
Sent: Wednesday, September 24, 2003 10:42 AM
Subject: RE: Speed differences between <jsp:include> and <c:import>

> Just out of curiousity. Unless the code is doing something short of
> ridiculous.. How much of a speed difference could there really be? I mean
> what exactly are u looking for? Would a difference of 100 milli effect the
> outcome of ur app? 1 sec even? What is the you main concern?
> -Tim
> -----Original Message-----
> From: Serge Knystautas []
> Sent: Wednesday, September 24, 2003 9:35 AM
> To: Tag Libraries Users List
> Subject: Re: Speed differences between <jsp:include> and <c:import>
> Sgarlata Matt wrote:
> > Does anyone know if there are any speed differences between using
> > <jsp:include> and <c:import> if one is including a file that is local
> the
> > web server?  Obviously if one does <c:import> and imports a file from a
> > remote web server that will be slower than including something on the
> local
> > server.
> >
> > Sorry if this is a common question, but I searched google, here and
> > struts-user and could not find an answer.
> Since c:import does what a jsp:include does if it a local resource, the
> difference should be minimal.  It is open source though, so I'd check
> out the code and see what is any extra processing is done.
> -- 
> Serge Knystautas
> President
> Lokitech >> software . strategy . design >>
> p. 301.656.5501
> e.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message