interpretated vs compiled

37 views
Skip to first unread message

Googie

unread,
Aug 16, 2003, 8:59:49 AM8/16/03
to
Hi!
I'm woundering if TCL script compiled (wrapped) to one executable is really
faster than interpretated by tcl interpreter?

If it's true, then can somebody explain me why? TCL interpreter
compiles/wraps script to binary on the fly and put them into the memory, am
I right? If I am, then it should be same as compiled/wrapped statically and
launched in this form... Difference could be only while launching process,
cos TCL interpreter has to compile/wrap script for each run.

Well, how is it?
--
Pozdrawiam (Greetings).
Googie

Michael Schlenker

unread,
Aug 16, 2003, 9:48:02 AM8/16/03
to
Googie wrote:
> Hi!
> I'm woundering if TCL script compiled (wrapped) to one executable is really
> faster than interpretated by tcl interpreter?
>
Depends. There were reports that scripts compiled with Andreas Otto's
COMPILER (i don't know if it is available any more) ran up to 20% faster.

There may be some small benefits for wrapped scripts as they usually
have tcl linked static, but that shouldn't be much. In general there
shouldn't be much differences, mainly a bit in the area of startup costs
and looking for packages in the filesystem.

Michael

Robert Heller

unread,
Aug 16, 2003, 10:10:30 AM8/16/03
to
Googie <do...@want.a.spam.org>,
In a message on Sat, 16 Aug 2003 14:59:49 +0200, wrote :

G> Hi!
G> I'm woundering if TCL script compiled (wrapped) to one executable is really
G> faster than interpretated by tcl interpreter?
G>
G> If it's true, then can somebody explain me why? TCL interpreter
G> compiles/wraps script to binary on the fly and put them into the memory, am
G> I right? If I am, then it should be same as compiled/wrapped statically and
G> launched in this form... Difference could be only while launching process,
G> cos TCL interpreter has to compile/wrap script for each run.
G>
G> Well, how is it?

The main reason people 'wrap' Tcl scripts into an executable is for
customer (end-user) convenience. Most customers don't want to have to
install Tcl/Tk on their machine just to run some random application.
Lots of people, *esp* in the MS-Windows and MacOS world, just want a
single .exe file that that can copy to some random folder/directory on
a random machine and just run and not have a whole tree of files
someplace that has to be copied/installed/deleted/un-installed, etc.
When a Tcl application is 'wrapped' into an executable, the end-user can
just copy 1 file (the application executable) to where they want to run
it. Afterward, they can just delete this *one* file (if they so
choose). Note: most wrappers don't 'compile' the Tcl script(s) -- the
scripts are still being interpreted by the Tcl interpreter, just that
the script file(s) are incorporated into the same executable as the
interpreter itself, generally using some sort of 'virtual file system'
that is laid out on the data portion of the executable (this is what
freewrap does, for example).

Speed, as such, is not the reason developers wrap Tcl scripts into an
executable.

G> --
G> Pozdrawiam (Greetings).
G> Googie
G>
G>

\/
Robert Heller ||InterNet: hel...@cs.umass.edu
http://vis-www.cs.umass.edu/~heller || hel...@deepsoft.com
http://www.deepsoft.com /\FidoNet: 1:321/153



Mike Tuxford

unread,
Aug 16, 2003, 11:54:59 AM8/16/03
to
Googie <do...@want.a.spam.org> wrote:
:Hi!

The premise 'that people wrap Tcl + scripts' for a speed
gain is faulty. That makes no sense since it's still an
interpreted language but just with the interperter built
into it.

--
_ _ ____
//\/\ike ||uxford
tux...@earthlink.net

Jeff Hobbs

unread,
Aug 18, 2003, 12:01:05 PM8/18/03
to

In general, no, it is not faster to wrap/precompile the script rather
than just loading off of disk. In terms of the Compiler (as from TclPro
or the Tcl Dev Kit), loading that code is actually a bit slower because
of the steps of obfuscation it goes through (the purpose of the Compiler
is more IP protection than anything else).

If you choose to just embed your Tcl code in C strings and eval it ...
well that is not far away from what Tcl does anyway. What you will save
is disk IO (and IO is usually slow), but that's about it.

--
Jeff Hobbs The Tcl Guy
Senior Developer http://www.ActiveState.com/
Tcl Support and Productivity Solutions

Cameron Laird

unread,
Aug 18, 2003, 1:48:04 PM8/18/03
to
In article <b5278$3f3e3b56$d0c7e1fd$32...@nf1.news-service.com>,
Robert Heller <hel...@deepsoft.com> wrote:
.
.

.
>Speed, as such, is not the reason developers wrap Tcl scripts into an
>executable.
.
.
.
I run into quite a few developers who *believe* they
should compile Tcl scripts to accelerate them. The
facts are against them, of course.
--

Cameron Laird <Cam...@Lairds.com>
Business: http://www.Phaseit.net
Personal: http://phaseit.net/claird/home.html

tun...@yahoo.com

unread,
Aug 18, 2003, 11:53:36 PM8/18/03
to
Jeff Hobbs <je...@activestate.com> wrote in message news:<5L60b.769674$3C2.17...@news3.calgary.shaw.ca>...

>
> In general, no, it is not faster to wrap/precompile the script rather
> than just loading off of disk. In terms of the Compiler (as from TclPro
> or the Tcl Dev Kit), loading that code is actually a bit slower because
> of the steps of obfuscation it goes through (the purpose of the Compiler
> is more IP protection than anything else).
>

I would be interested in learning more about the level of protection
that the compiler brings. Is it pretty good to keep from inspection?
How about from an experienced tcl developer?

Personally, the simplicity of wrapping plus bytecode compilation beats
any speed gains (real or imagined) any day in the real world.

lvi...@yahoo.com

unread,
Aug 19, 2003, 9:03:53 AM8/19/03
to

According to Mike Tuxford <tuxfor...@NORETURNearthlink.net>:
:Googie <do...@want.a.spam.org> wrote:
::I'm woundering if TCL script compiled (wrapped) to one executable is really

::faster than interpretated by tcl interpreter?

: The premise 'that people wrap Tcl + scripts' for a speed


:gain is faulty. That makes no sense since it's still an
:interpreted language but just with the interperter built
:into it.

Well, there are certainly many people who wish/falsely expect that
compiling tcl will give them speed. But as you say, their expectations
are faulty.

Their hope is that by 'compiling', one can skip the interpretation step -
that once the bytecompiler has compiled the tcl code into byte codes, if
they could save that form the application would speed up.

The problem is that it is not obvious to a developer where an application
is in the various phases of tcl's interpreter so that they can properly
instrument and measure the speeds of the software.


Here are at least some of the phases of which I am aware when running
a tcl script via #! /path/to/tcl_interpreter .

1. Operating system loads the tcl interpreter
2. Encoding file located and loaded (??)
3. Interpreter begins interpreting script
4. If a package require is performed, Tcl reads through the interpreter's
auto_path directory trees to locate and execute all package index
files.
5. If procs are defined, they are byte compiled.
7. interpreter either reads and interprets source code or byte code.
--
<URL: http://wiki.tcl.tk/ > <URL: http://www.tcl.tk/ >
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lvi...@yahoo.com > <URL: http://www.purl.org/NET/lvirden/ >

Jeff Hobbs

unread,
Aug 19, 2003, 11:08:24 AM8/19/03
to
tun...@yahoo.com wrote:
> Jeff Hobbs wrote in message news:<5L60b.769674$3C2.17...@news3.calgary.shaw.ca>...

>
>>In general, no, it is not faster to wrap/precompile the script rather
>>than just loading off of disk. In terms of the Compiler (as from TclPro
>>or the Tcl Dev Kit), loading that code is actually a bit slower because
>>of the steps of obfuscation it goes through (the purpose of the Compiler
>>is more IP protection than anything else).

> I would be interested in learning more about the level of protection
> that the compiler brings. Is it pretty good to keep from inspection?
> How about from an experienced tcl developer?

It has worked so far for protecting IP. There is no way to introspect
into a precompiled proc at runtime. Asking for 'info body' will give
you a simple error string, although the proc otherwise works. It is
very effective for IP protection. From the experienced Tcl developer?
It is possible to reverse engineer what is done, but it wouldn't be
trivial, and it would require someone with significant knowledge of
Tcl's bytecode engine.

> Personally, the simplicity of wrapping plus bytecode compilation beats
> any speed gains (real or imagined) any day in the real world.

Yes, it certainly does make life easier.

Mike Tuxford

unread,
Aug 19, 2003, 11:24:26 AM8/19/03
to
tun...@yahoo.com wrote:
:Jeff Hobbs <je...@activestate.com> wrote in message news:<5L60b.769674$3C2.17...@news3.calgary.shaw.ca>...

:>
:> In general, no, it is not faster to wrap/precompile the script rather
:> than just loading off of disk. In terms of the Compiler (as from TclPro
:> or the Tcl Dev Kit), loading that code is actually a bit slower because
:> of the steps of obfuscation it goes through (the purpose of the Compiler
:> is more IP protection than anything else).
:>
:
:I would be interested in learning more about the level of protection
:that the compiler brings. Is it pretty good to keep from inspection?
:How about from an experienced tcl developer?

Depends on what you mean and/or expect for "protection".
I am not a C programmer but a simple wrapped and compiled
interpretor + script (either static or dynalic linked libs)
the script will all show up in a `strings <tcl binary>` via
any linux/unix system. Wrapper apps like mktclapp can
encrypt the Tcl script thus "hiding" it from my level of
knowledgde. That is, a `strings <binary>` will show encoded
garbage instead of the script.

:Personally, the simplicity of wrapping plus bytecode compilation beats


:any speed gains (real or imagined) any day in the real world.

Some of the reasons I've seen or heard for people to
build stand-alone executables is:

1) Static-linked wrapping allows an application to run on
machines that do not even have Tcl or Tk installed, not to
mention concerns about versions.

2) A developer may deal with a target admin who has stated
up front the requirement that they do not want a solution
that needs any additional system lib maintenance from them.
Wrapping would keep such admins happy since everything
needed can be staticly linked and builtin.

3) A developer or an admin may want to 'hide' the script
code from the users by encrypting it. The admin could
still have the source but keep the scripts from less than
benevolent users. A single binary can have a checksum for
security.

Jeff Hobbs

unread,
Aug 19, 2003, 11:52:02 AM8/19/03
to
Mike Tuxford wrote:

> tun...@yahoo.com wrote:
> :Jeff Hobbs wrote in message news:<5L60b.769674$3C2.17...@news3.calgary.shaw.ca>...


> :>
> :> In general, no, it is not faster to wrap/precompile the script rather
> :> than just loading off of disk. In terms of the Compiler (as from TclPro
> :> or the Tcl Dev Kit), loading that code is actually a bit slower because
> :> of the steps of obfuscation it goes through (the purpose of the Compiler
> :> is more IP protection than anything else).
> :>
> :
> :I would be interested in learning more about the level of protection
> :that the compiler brings. Is it pretty good to keep from inspection?
> :How about from an experienced tcl developer?
>
> Depends on what you mean and/or expect for "protection".
> I am not a C programmer but a simple wrapped and compiled
> interpretor + script (either static or dynalic linked libs)
> the script will all show up in a `strings <tcl binary>` via
> any linux/unix system. Wrapper apps like mktclapp can
> encrypt the Tcl script thus "hiding" it from my level of
> knowledgde. That is, a `strings <binary>` will show encoded
> garbage instead of the script.

This is true of some, but not for Tcl Dev Kit Compiler. Your code is
actually obfuscated at multiple levels.

> :Personally, the simplicity of wrapping plus bytecode compilation beats
> :any speed gains (real or imagined) any day in the real world.
>
> Some of the reasons I've seen or heard for people to
> build stand-alone executables is:
>
> 1) Static-linked wrapping allows an application to run on
> machines that do not even have Tcl or Tk installed, not to
> mention concerns about versions.

And you can do this without all the extra effort of special compilation
by using prowrap or the newer starkit-based TclApp.

> 2) A developer may deal with a target admin who has stated
> up front the requirement that they do not want a solution
> that needs any additional system lib maintenance from them.
> Wrapping would keep such admins happy since everything
> needed can be staticly linked and builtin.
>
> 3) A developer or an admin may want to 'hide' the script
> code from the users by encrypting it. The admin could
> still have the source but keep the scripts from less than
> benevolent users. A single binary can have a checksum for
> security.

Again, both of those are satisfied by easier wrapping solutions,
although you can still choose to recompile if you want.

Reply all
Reply to author
Forward
0 new messages