Hi Lee.
It sounds like you have uncovered a speed problem in the subst command
implementation. There is nothing at all wrong with implementing your
own commands to replace "standard" commands, but you might want to
think about optimizing the subst command before you give up and replace
it.
There are two main reasons why improving the subst implementation
might be a better way to go. First, your improvements would be
available to everyone. Second, you would not need to maintain
your special "hacked" version of subst. Coding for
"the good of everyone" is a nice concept, but I have found that
there is a much more selfish reason you should look at fixing the
subst command before you go off an implement your own. I have found
that one of the biggest "costs" of upgrading a project that depends
on an external library (like Java or Tcl/Tk itself) is updating the
"local hacks" that you made to the core. When the core changes, you
end up going back and fixing up your local hacks. This can take a
VERY long time! Much longer than it might have taken to just improve
the core in the first place.
For example, you mentioned that there were some string concatenations
in the source that could be replaced by StringBuffer.append() calls.
I took a quick look at the source, and you are right, there is some
code in there that is just plain wrong (Don't blame me, I didn't do it).
There is some code like this:
String result = "";
result = result + vres.value.toString();
This kind of thing is really wasteful and can be made much faster
using a StringBuffer as you suggest. If you want to fix the subst
implementation so that it uses a StringBuffer, create a patch
and post it to the list and I will check it into the CVS.
You will want to get the CVS version to make the patch.
You also mentioned "Since Interpret.evalFlags and Parser are only package
accessible". What were you trying to do that Jacl did not allow? Can
you do the same thing in the C version of Tcl? If so, how?
later
Mo DeJong
Red Hat Inc.
On Thu, 23 Mar 2000, Lee Hall wrote:
> It seems like what I had to do to implement a new version of the "subst"
> command was a hack. The new command is "weld". I would have preferred to
> stick with standard JACL on this, but the results of the "time" command
> justified the replacement:
>
> weld {242700 microseconds per iteration}
> subst {459500 microseconds per iteration}
> weld {243800 microseconds per iteration}
> subst {456400 microseconds per iteration}
> weld {242600 microseconds per iteration}
> subst {454600 microseconds per iteration}
>
> Each timing ran in sequence to eliminate any variances due to
> initialization. The input for each iterated 10 times, and the original
> script started as 2810 "source" bytes and resulted as 6369 bytes after
> substitutions. The "weld" command is identical to subst in function, but
> eliminates the options and uses StringBuffer.append() to accumulate the
> result instead of String concatenation.
>
> At first, I thought I could just write the new command in my own package.
> Since Interpret.evalFlags and Parser are only package accessible, I then
> thought that I could just relocate the command in tcl.lang and make WeldCmd
> public so that I could use Interp.createCommand to load it. This caused
> IllegalAccessException at runtime.
>
> I didn't want to build a new, non-standard JACL that included the command,
> so I changed the access back to package and tried using
> Extension.loadOnDemand() - which worked.
>
> Is this technique correct, or am I trying to do something that violates the
> design philosophy? Recommendations would be appreciated.
>
> - Lee
----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe: send mail to [EMAIL PROTECTED]
with the word SUBSCRIBE as the subject.
To unsubscribe: send mail to [EMAIL PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
