I think 2-3 milliseconds for each use of the tag is a very big burden. I don't cache on my dev server, so I'm seeing this on each use of the tag, which makes the dev system completely unrepresentative of the production system. Turning the cache on would just add a purge cache step to my develpment, which is just something else to get in the way of productivity.

If the Custom Tag Object was instantiated in a persistent scope, then presumably this would not be an issue.

So I guess this is now more of a feature request:
* instantiate custom tags in a persistent (ie., system) scope so they are available across applications.

On Oct 10, 2006, at 12:38 PM, Robert Shubert wrote:

Actually, the first stanza you have showing the request for the file showing the path is actually checking for that file (at that path and domain) in the application file cache. It is not actually accessing the disk unless it fails to locate the file in the cache. It's also notable that Witango stores TAFs and TCFs in its cache in a parsed form, so it will skip both the disk read and XML parsing steps if you have caching active and the file has been
previously accessed.

This is more or less proven in your debug because the amount of time to
"get" the file is extremely low 2-3 ms.

As for using a method in a TCF as you show below, that always happens
against a variable, which is - by definition - always in memory.

Robert

-----Original Message-----
From: William M Conlon [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 10, 2006 2:58 PM
To: [email protected]
Subject: Re: Witango-Talk: custom tags

I want to follow up on this, because the big inefficiency is disk
access, and I see repeated log entries for the custom tag:

09/10/2006      13:47:25        66.219.95.118   [EMAIL PROTECTED]
-1460044880     1       155             [Thread] Getting network
file /path_to_TCFs/ISINT.tcf
09/10/2006      13:47:25        66.219.95.118   [EMAIL PROTECTED]
-1460044880     1       155             [Thread] Got file
09/10/2006      13:47:25        66.219.95.118   [EMAIL PROTECTED]
-1460044880     1       157             [Thread] Network file
loaded: /path_to_/TCFs/ISINT.tcf
09/10/2006      13:47:25        66.219.95.118   [EMAIL PROTECTED]
-1460044880     1       158             [Application
File]              /TCFs/ISINT.tcf

But for pre-existing objects, the disk access is not needed:

09/10/2006      13:47:25        66.219.95.118   [EMAIL PROTECTED]
-1460044880     1       154             [Call Method Action]
topic_access_check
09/10/2006      13:47:25        66.219.95.118   [EMAIL PROTECTED]
-1460044880     1       154             [Query] [Invocation of method
"topic_access_check" of object "TCF://forum.tcf:Domain$forumObj" with
parameters [id=18, org_id=301, user_access_level=11, public=yes,
owner_id=11]
09/10/2006      13:47:25        66.219.95.118   [EMAIL PROTECTED]
-1460044880     1       155             [Application
File]              TCFs/forum.tcf


Can the Custom Tag be instantiated in System Scope by changing the
object definition, which comes out of the tag generator as local scope:

                        <objectdef id="ISINT_obj" type="TCF">
                                <name>ISINT.tcf</name>
                                <varname>ISINT_obj</varname>
                                <scope>local</scope>
                        </objectdef>

Or is there some other trick so the object can be instantiated by
witangod at startup, so the tag is always available?

On Oct 10, 2006, at 8:27 AM, Robert Shubert wrote:

1.  The server looks for the class on each use, which is HIGHLY
inefficient.   I would have thought that a Custom Tag would get
loaded in system scope and be optimized in various ways.  (Always
loaded for example).   Can this be adjusted with the tag definition
xml?  I notice that the object definition provided by the custom tag
generator specifies local scope.  If I changed this to system scope,
would the tag then be always loaded and persistent?

As long as the TCF is found in the first place the server looks,
and is
cached in the application cache, this process should not be
terribly time
consuming.

Bill

William M. Conlon, P.E., Ph.D.
To the Point
345 California Avenue Suite 2
Palo Alto, CA 94306
    vox:  650.327.2175 (direct)
    fax:  650.329.8335
mobile:  650.906.9929
e-mail:  mailto:[EMAIL PROTECTED]
    web:  http://www.tothept.com

______________________________________________________________________ __
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf

______________________________________________________________________ __
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf

Bill

William M. Conlon, P.E., Ph.D.
To the Point
345 California Avenue Suite 2
Palo Alto, CA 94306
   vox:  650.327.2175 (direct)
   fax:  650.329.8335
mobile:  650.906.9929
e-mail:  mailto:[EMAIL PROTECTED]
   web:  http://www.tothept.com

________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf

Reply via email to