Home > Archive > Tcl > February 2007 > C vs Tcl again...
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| call_me_anything 2007-01-25, 8:08 am |
| Is Tcl very very slow ?
I read somewhere that its approximately 150 times slower than C.
How do Java and Tcl compare in terms of efficiency ?
Don't both of them use byte code compiling ?
I understand C vs Tcl.
But why such a huge difference ?
This renders Tcl unusable for many many purposes !
My main concern is drawing widgets using Tcl/Tk and writing huge amount
of similar code in C to achieve efficiency. Is it worth to take such
trouble via C ?
| |
| Gerald W. Lester 2007-01-25, 7:09 pm |
| call_me_anything wrote:
> Is Tcl very very slow ?
> I read somewhere that its approximately 150 times slower than C.
I've not heard the 150 number, some things you want to do in C ... but very few.
It can sometimes be **faster** in Tcl then if you write it in C --
particularly if you use libraries in C to "assist" you in writing the code.
> How do Java and Tcl compare in terms of efficiency ?
> Don't both of them use byte code compiling ?
>
> I understand C vs Tcl.
> But why such a huge difference ?
> This renders Tcl unusable for many many purposes !
What purposes would those be?
Not near real time control systems -- there are a good number of cases where
Tcl is being used for that.
> My main concern is drawing widgets using Tcl/Tk and writing huge amount
> of similar code in C to achieve efficiency. Is it worth to take such
> trouble via C ?
If you are doing a GUI, you are very unlikely to see any place where Tcl/Tk
is slower than C -- and those few places (such as a real time bar chart or
oscilloscope) Tk has extensions to deal with.
In general, I suspect any GUI you write in C will be slower and have more
bugs and more serve bugs than one written in Tcl/Tk.
When I first started using Tcl/Tk, the evaluation task was to duplicate a
GUI written by a supplier of ours that was written in C/C++. This GUI
navigated and displayed low level information about a real time network
database. When done in Tcl/Tk it was about 2 times faster and used 5 times
less memory than the one in C/C++. (Since it was our first Tcl/Tk program it
was later rewritten using proper Tcl/Tk methods -- its speed was improved by
about 25% and the size reduced about 10%)
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
| |
| Cameron Laird 2007-01-25, 7:09 pm |
| In article <1169732860.435526.66550@a34g2000cwb.googlegroups.com>,
call_me_anything <sgiit@yahoo.com> wrote:
>Is Tcl very very slow ?
>I read somewhere that its approximately 150 times slower than C.
>
>How do Java and Tcl compare in terms of efficiency ?
>Don't both of them use byte code compiling ?
>
>I understand C vs Tcl.
>But why such a huge difference ?
>This renders Tcl unusable for many many purposes !
>
>My main concern is drawing widgets using Tcl/Tk and writing huge amount
>of similar code in C to achieve efficiency. Is it worth to take such
>trouble via C ?
>
No.
I predict that, if you try to write your own widgets, your C-coded
program, instead of being 150 times as fast as the corresponding
Tcl one, will be SLOWER.
The place where you read that Tcl is "approximately 150 times slower
than C" ... deceived you.
| |
| suchenwi 2007-01-25, 7:09 pm |
| And also, Tcl and Tk are implemented in C :)
| |
| Peter Dalgaard 2007-01-25, 7:09 pm |
| claird@lairds.us (Cameron Laird) writes:
> In article <1169732860.435526.66550@a34g2000cwb.googlegroups.com>,
> call_me_anything <sgiit@yahoo.com> wrote:
>
> No.
>
> I predict that, if you try to write your own widgets, your C-coded
> program, instead of being 150 times as fast as the corresponding
> Tcl one, will be SLOWER.
At best a few percent faster if you are a VERY good C programmer.
> The place where you read that Tcl is "approximately 150 times slower
> than C" ... deceived you.
Yes, it needs qualification: very fine-grained code, in which each Tcl
command does very little (say, adds two numbers) will be that much
slower than equivalent C code, maybe even worse. So don't plan to code
up numerical integration or eigenvalue decomposition in Tcl.
You can, however, extend your Tcl interpreter with commands written in
C, bringing you the best of both worlds.
--
O__ ---- Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907
| |
| Volker Hetzer 2007-01-25, 7:09 pm |
| call_me_anything schrieb:
> Is Tcl very very slow ?
> I read somewhere that its approximately 150 times slower than C.
Depends on the type of program but for "real" computations this sounds
realistic. On certain systems it's probably even slower when compared to
Fortran. Or assembler.
On the other hand, a program going
set F [read [set H [open /tmp/x.txt {RDONLY}]]]
puts [expr [regexp "XXX" $F]?1:0]
close $H
won't be much slower than the equivalent C program.
> How do Java and Tcl compare in terms of efficiency ?
> Don't both of them use byte code compiling ?
Shouldn't make much of a difference.
> I understand C vs Tcl.
> But why such a huge difference ?
Because Tcl is byte code compiled and C (usually) is not.
> This renders Tcl unusable for many many purposes !
Yes. For instance you don't really want to do a finite elements computation in
Tcl. Ditto for rendering, RSA competitions, image processing, automatic voice
translation, processing of radio telescope data and mass internet surveillance.
On the other hand, the things that make Tcl slow make it perfectly usable for
many many other purposes!
Like text file processing, Gui development, prototypes, systems integration,
basically everything that has a user at the other end and doesn't require
massive number crunching. In addition, Tcl programs have no memory access
violations, dont't core dump and generally achieve with one line of code
things that would require hundreds of lines of code in C. So, as soon
as programmer efficiency is a requirement, Tcl has its hat in the ring,
as you have discovered. Which is why you are trying to work with Tcl,
right?
> My main concern is drawing widgets using Tcl/Tk and writing huge amount
> of similar code in C to achieve efficiency. Is it worth to take such
> trouble via C ?
That depends on how much your working time is worth and how much the end
result is worth. We cannot really advise on that. But /any/ Tcl program
trying to display one million objects in the way you plan, will probably
be unusable.
You know, there /is/ a reason why software companies exist and spend
lots of programmer time to get these things right. I love Tcl but will learn
COM/ATL programming this year for some serious data processing. But of course,
any user interfaces, Test harnesses and other things will be done by Tcl or
some other suitable tool.
Lots of Greetings!
Volker
--
For email replies, please substitute the obvious.
| |
| Bryan Oakley 2007-01-25, 7:09 pm |
| call_me_anything wrote:
> I understand C vs Tcl.
> But why such a huge difference ?
> This renders Tcl unusable for many many purposes !
Why is that something to be concerned about? Python is unsuitable for
many purposes, as is perl, java, c#, VB, etc. No one language is
suitable for everything.
Don't learn Tcl (or any language) with the misunderstanding that it's
the only language you'll ever need to learn. Use the right tool for the
job. Sometimes that tool will be Tcl. Sometimes not. Rejoice in the
former and hire someone else to do the latter :-)
> My main concern is drawing widgets using Tcl/Tk and writing huge amount
> of similar code in C to achieve efficiency. Is it worth to take such
> trouble via C ?
>
No.
I have never noticed any speed problems with creating GUIs in Tk, at
least as far as creating and managing the widgets is concerned. You can
easily create tens of thousands of widgets (*) in well under a second.
Given that most UIs only have perhaps a few hundred, tk is plenty fast
enough.
Of course, the actions those widgets may initiate may be slow, but the
creation of the GUI is lickety-split (or can be, if done right). One of
the advantages of using Tcl is you can write those slow bits in C if you
want.
(*) for that number I created a simple loop creating and packing buttons
and text widgets. On my slow windows laptop I could create 10000 widgets
in around 5ms. Is that fast enough for you?
--
Bryan Oakley
www.tclscripting.com
| |
| Neil Madden 2007-01-25, 7:09 pm |
| Bryan Oakley wrote:
> call_me_anything wrote:
>
>
> Why is that something to be concerned about? Python is unsuitable for
> many purposes, as is perl, java, c#, VB, etc. No one language is
> suitable for everything.
To add to that point: The fact that C has relatively limited means of
abstraction, no way to create custom control constructs, and no
automatic memory management makes *it* unsuitable for many many
purposes. On the other hand, Tcl + C together are suitable for a very
large number of purposes.
-- Neil
| |
| Larry W. Virden 2007-01-25, 7:09 pm |
|
On Jan 25, 8:47 am, "call_me_anything" <s...@yahoo.com> wrote:
> Is Tcl very very slow ?
> I read somewhere that its approximately 150 times slower than C.
:
> My main concern is drawing widgets using Tcl/Tk and writing huge amount
> of similar code in C to achieve efficiency. Is it worth to take such
> trouble via C ?
You ask "Is Tcl very very slow"? Many people have responded different
ways. My first thought was "well, while Tcl and the other interpreted
languages may be slower than C, they are quite often "fast enough"."
The most common suggestion in the comp.lang.tcl community is "tcl is
pretty simple to learn the basics - spend a day, learn basic tcl and
tk, then prototype what you are trying to do. If THAT is too slow, come
back and ask here how to make a specific problem faster."
You had concern about drawing widgets. Generally, widgets _are_ written
in C. Code USING the widgets are generally written in a scripting
language. That's because Tcl, and computers, tend to be MUCH faster
than the humans using the programs.
If there's a piece of your program which needs high speed data
acquisition, or calculations, etc., then it is relatively trivial to
write some C (or FORTRAN, etc.) code which you then could call from
Tcl.
There are at times specific application domains where writing
everything in core Tcl/Tk scripts is not practical. In those cases,
profiling the system so that you find out where the real bottlenecks
are located, then determining whether better coding, better algorithms,
or writing in Java/C/assembler is required.
| |
|
| call_me_anything <sgiit@yahoo.com> wrote:
> I understand C vs Tcl.
> But why such a huge difference ?
> This renders Tcl unusable for many many purposes !
I've never seen any particilar slowness I'd blame distinctly on Tcl for
day to day programming -- and my current Tcl project is a multi platform
OpenGL arcade game ;-).
I'm sure you could make a case of such and such a function in C is
technically faster than something else in Tcl, but, on today's hardware,
your project's going to have to be mighty complex or working on vast
amounts of data before it'll make the slightest bit of difference to
your users.
Meanwhile, Tcl provides a lot of basics that don't come easy with C.
I've never seen a Tcl app fall over and take an entire machine down in
the same way that bad C/C++ code can.
If there is a bottleneck that would be better written in C, it's also
easy for you to create your compiled code and then use it with Tcl. So
you really do get the best of all words.
| |
| Ian Bell 2007-01-25, 7:09 pm |
| call_me_anything wrote:
> Is Tcl very very slow ?
> I read somewhere that its approximately 150 times slower than C.
>
Care to say where?
ian
| |
| Ian Bell 2007-01-25, 7:09 pm |
| Gerald W. Lester wrote:
>
> In general, I suspect any GUI you write in C will be slower and have more
> bugs and more serve bugs than one written in Tcl/Tk.
>
Although I am a Tcl/Tk advocate (and user/coder) I have to take issue with
this statement. There are C based GUI toolkits (gtk for instance) that
provide much the same functionality as Tk but with a C interface. In fact I
used to code gtk GUI apps in C before moving to Tcl/Tk. The reason I made
the move is that it is just as easy to write a GUI in Tk as it is in gtk,
but it is so much easier to write remainder of the application code in Tcl.
Ian
| |
| Ian Bell 2007-01-25, 7:09 pm |
| Bryan Oakley wrote:
>
> I have never noticed any speed problems with creating GUIs in Tk, at
> least as far as creating and managing the widgets is concerned. You can
> easily create tens of thousands of widgets (*) in well under a second.
> Given that most UIs only have perhaps a few hundred, tk is plenty fast
> enough.
>
It's probably even faster than that. At present I am playing with coding a
simple electronics CAD program and I have coded resistors, capacitors,
transistors and inductors as simple combinations of lines and arcs on a
canvas widget. I have run some timing test and you can draw 10,000 of any
of these components in just over a second.
Ian
| |
|
| Some time ago (>5yr) I wrote a 2D display package for IC mask data. The
canvas widget didn't slow down noticeably until there where more than
~250,000 item. I selected the tk canvas for this project because my
Java test indicate that performance would be terrible or development
time would be excessively long.
Tom K.
On Jan 25, 1:28 pm, Ian Bell <ruffreco...@yahoo.co.uk> wrote:
> Bryan Oakley wrote:
>
> simple electronics CAD program and I have coded resistors, capacitors,
> transistors and inductors as simple combinations of lines and arcs on a
> canvas widget. I have run some timing test and you can draw 10,000 of any
> of these components in just over a second.
>
> Ian
| |
| Ian Bell 2007-01-26, 4:13 am |
| Gerald W. Lester wrote:
> Ian Bell wrote:
>
> Ian, please read what the OP said his plans were -- "writing huge amount
> of
> similar code in C". If he was going to use one of better toolkits, he
> would not be writing "writing huge amount of similar code in C".
>
I was responding you your point not the OP's, and in particular your
phrase 'In general'
Ian
| |
| call_me_anything 2007-01-27, 7:07 pm |
| Thanks Shaun for reading my earlier posts too.
You have hit upon my exact requirements.
Can you also suggest how can I get started with another language for
writing my own widget ?
Also, do you know of some good tool which can be used as a Tcl/Tk
IDE ?
Any tools for automatic documentation and funcion call graph
generators would also be highly welcome.
My exact need here is a tool which can show the call graphs between C,
Tcl, Tk, Itcl and Itk.
If I can edit the code and add comments while viewing the call graph,
whew ! It would just save me a huge amount of time and effort.
On Jan 25, 10:02 am, "Shaun Deacon" <sdea...@fma.fujitsu.com> wrote:
> As others have commented, it really on depends what you're trying to
> do. From your other posts I gather that you're trying to write an EDA
> tool to view timing/test waveforms.
>
> Tcl/Tk is still your friend here. It is easy and quick to create good
> quality GUI's for this purpose. I would argue, maybe much faster than
> with other toolkits/languages. Also, depending on what you want to
> display (and the amount of data) the canvas widget is definitely fast
> enough...even with 100,000+ objects the performance is good - as others
> have mentioned.
>
> In another thread, you mentioned that you may want to display millions
> of lines. Others commented in that thread that you need to think
> carefully about your design as a naive approach will render slowly in
> any toolkit/language and may even be difficult/impossible/or
> unnecessary to completely visualize. Organizing the display in a
> different way or rendering fewer objects could still give the effect
> you're after while maintaining a reasonable performance.
>
> However, if you're still intent on rendering millions of objects, then
> the native Tk canvas may not be suitable. I developed a physical layout
> viewer which needed to display a chip image of millions of physical
> cells and nets at full view - the canvas widget was a little sluggish
> in this case.
>
> Tcl was developed as a 'glue' language and will seemlessly integrate
> with other languages where it's more appropriate - this is one of the
> great advantages. So, in my case, I developed my own widget in C++ to
> display the chip layout.
>
> The beauty is that a 'custom' widget in another language can be called
> and configured like any other Tk widget. It can be dropped directly
> into the rest of a GUI with minimal effort and even instantiated
> multiple times (I actually use my widget in multiple tools)
>
> Basically, I think Tcl/Tk will still be the right tool for you. You
> should be able to prototype and develop an overall GUI quickly and
> easily. I think if you consider the waveform display design carefully,
> the Tk canvas should be more than adequate. If not, it won't be
> difficult to create this part in another language (eg. C/C++) and
> integrate it in.
>
> HTH,
> Shaun
| |
| call_me_anything 2007-01-27, 7:07 pm |
| Can you give me an example of custom loop iterators in Tcl.
I ... well.. ahem.. never heard of any such thing.
| |
| Gerald W. Lester 2007-01-27, 7:07 pm |
| call_me_anything wrote:
> Can you give me an example of custom loop iterators in Tcl.
> I ... well.. ahem.. never heard of any such thing.
http://wiki.tcl.tk/2025
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
| |
| Cameron Laird 2007-01-27, 10:07 pm |
| In article <1169903328.152742.112060@a34g2000cwb.googlegroups.com>,
call_me_anything <sgiit@yahoo.com> wrote:
>Thanks Shaun for reading my earlier posts too.
>You have hit upon my exact requirements.
>
>Can you also suggest how can I get started with another language for
>writing my own widget ?
>Also, do you know of some good tool which can be used as a Tcl/Tk
>IDE ?
>Any tools for automatic documentation and funcion call graph
>generators would also be highly welcome.
>My exact need here is a tool which can show the call graphs between C,
>Tcl, Tk, Itcl and Itk.
>If I can edit the code and add comments while viewing the call graph,
>whew ! It would just save me a huge amount of time and effort.
| |
| Donal K. Fellows 2007-01-28, 7:10 pm |
| call_me_anything wrote:
> Can you give me an example of custom loop iterators in Tcl.
> I ... well.. ahem.. never heard of any such thing.
One example is some code I wrote one time when I needed to parse a
large number of files containing mail messages. (Or at least, the
contents were formatted like mail messages; what they actually were
doesn't matter here.) Now, I needed to do this from many places in the
program, and in each place I was doing something like this:
foreach dir $path {
foreach file [glob $dir/*.msgs] {
set f [open $file]
set contents [read $f]
close $f
foreach msg [splitByMessage $contents] {
array set hdr [getHeaders $msg]
set bodyParagraphs [getBodyParas $msg]
# Now came the bit that varied. This is an example
if {![string match *Donal* $hdr(To)]} {
applyBayesianFiltering [lrange $bodyParagraphs 0 3]
}
# End of variant part
unset hdr
}
}
}
OK, that's not too bad. But the program had quite a lot of these - I
think it had got up to something like 15 by the point I refactored,
and I'd been having problems with making sure that I cut-n-paste the
code correctly each time - so I instead factored it out so I got it
right *once* and then everywhere else could just work at the level
where I was really thinking. I ended up writing a procedure like this:
proc foreachMessageOnPath {hdrAry bodyVar script} {
upvar 1 $hdrAry hdr $bodyVar bodyParagraphs
global path
array set hdr {}
foreach dir $path {
foreach file [glob $dir/*.msgs] {
set f [open $file]
set contents [read $f]
close $f
foreach msg [splitByMessage $contents] {
unset hdr
array set hdr [getHeaders $msg]
set bodyParagraphs [getBodyParas $msg]
uplevel 1 $script
}
}
}
}
With this, that above complex example becomes this:
foreachMessageOnPath header body {
if {![string match *Donal* $header(To)]} {
applyBayesianFiltering [lrange $body 0 3]
}
}
Now, isn't that just so much clearer? All that complex structure is
now gone; just the interesting bits are left. And that's exactly why
custom control structures are good.
I mentioned earlier that I'd done such things in C too. I present a
couple of examples here (they're much lower-level, but work well and
make a lot of code less error-prone).
#define FOREACH(var,ary) \
for(i=0 ; (i<(ary).num?((var=(ary).list[i]),1):0) ; i++)
#define FOREACH_HASH(key,val,tablePtr) \
for(hPtr=Tcl_FirstHashEntry((tablePtr),&search); hPtr!=NULL ? \
((key)=(void *)Tcl_GetHashKey((tablePtr),hPtr),\
(val)=Tcl_GetHashValue(hPtr),1):0;\
hPtr=Tcl_NextHashEntry(&search))
If you use them, be aware that they make big assumptions about the
underlying data structures and, especially, the meaning of some
variables. Mind you, anyone writing C code that follows the style
outlined in the Tcl Engineering Manual would probably make the same
sorts of assumptions anyway. :-)
Donal.
| |
| Mark Janssen 2007-01-28, 7:10 pm |
| On Jan 28, 5:40 pm, "Donal K. Fellows" <donal.k.fell...@man.ac.uk>
wrote:
> call_me_anything wrote:
> large number of files containing mail messages. (Or at least, the
> contents were formatted like mail messages; what they actually were
> doesn't matter here.)
Another nice example is to refactor for instance the following snippet
set f [open file]
# do something with $f
close $f
I don't want to worry about closing the file after I am done with it
so I use:
proc with-file {name var block} {
upvar $var file
set file [open $name]
set res [uplevel 1 $block]
close $file
return $res
}
This creates a new control structure for working with a file without
having to worry about closing it for example:
with-file filename f { read $f }
will open the file, read it, close the file and return the contents of
the file.
Mark
| |
| Mark Janssen 2007-01-28, 7:10 pm |
|
On Jan 28, 7:31 pm, "Mark Janssen" <mpc.jans...@gmail.com> wrote:
> On Jan 28, 5:40 pm, "Donal K. Fellows" <donal.k.fell...@man.ac.uk>
> wrote:
>
>
> set f [open file]
>
> # do something with $f
>
> close $f
>
> I don't want to worry about closing the file after I am done with it
> so I use:
>
> proc with-file {name var block} {
> upvar $var file
> set file [open $name]
> set res [uplevel 1 $block]
> close $file
> return $res
>
> }This creates a new control structure for working with a file without
> having to worry about closing it for example:
>
> with-file filename f { read $f }
>
> will open the file, read it, close the file and return the contents of
> the file.
>
> Mark
Or with a catch to prevent the file staying open if $block contains
invalid Tcl code:
proc with-file {name var block} {
upvar $var file
set file [open $name]
set code [catch {uplevel 1 $block} res]
close $file
return -code $code $res
}
Mark
| |
|
|
| Mark Janssen 2007-01-28, 7:10 pm |
|
On Jan 28, 11:10 pm, Neil Madden <n...@cs.nott.ac.uk> wrote:
> Mark Janssen wrote:...
>
>
> -- Neil
Hehe, that shows that everything you need is already on the wiki (if
you know what to look for). I am relieved of course that the code is
very similar.
Mark
| |
| slebetman@yahoo.com 2007-01-28, 10:09 pm |
| On Jan 27, 9:10 pm, "call_me_anything" <s...@yahoo.com> wrote:
> Can you give me an example of custom loop iterators in Tcl.
> I ... well.. ahem.. never heard of any such thing.
Unlike most other languages, creating custom control structures in Tcl
is not only possible, it's easy. Loop iterators is one of the easiest
control construct to implement. Take tcllib's fileutil::foreachLine is
a good example of a pure Tcl custom iterator. It not only implement a
while+gets loop but also takes care of opening and closing the file.
And it's indeed easy to implement, you don't even need tcllib:
proc eachline {var filename script} {
upvar 1 $var v
set f [open $filename r]
while 1 {
set v [gets $f]
if {[eof $f]} break
uplevel 1 $script
}
close $f
}
Here's another custom looping construct that does directory recursion
on a given path and execute a script for each file/directory listed:
proc dirscan {var path script} {
upvar 1 $var v
foreach v [glob -nocomplain -directory $path *] {
uplevel 1 $script
if {[file isdirectory $v]} {
dirscan $var $v $script
}
}
}
There are lots of pages on the wiki where you'll find custom loop
constructs. The following are a few examples:
http://wiki.tcl.tk/17444 allows you to insert iterator in [foreach]
http://wiki.tcl.tk/17471 implements list comprehension
http://wiki.tcl.tk/17475 implements monads
| |
| suchenwi 2007-01-29, 8:07 am |
|
On 29 Jan., 03:20, "slebet...@yahoo.com" <slebet...@gmail.com> wrote:
> proc eachline {var filename script} {
> upvar 1 $var v
> set f [open $filename r]
> while 1 {
> set v [gets $f]
> if {[eof $f]} break
> uplevel 1 $script
> }
> close $f
> }
Note however that it's simpler to write:
proc eachline {_var filename script} {
upvar 1 $_var v
set f [open $filename]
while {[gets $f v] >= 0} {
uplevel 1 $script
}
close $f
}
}
| |
| Stephan Kuhagen 2007-02-14, 4:15 am |
| MH wrote:
> For example, we transfer ascii data for a certain operation. Parsing 50K
> lines in Tcl took ~8 seconds, using several approaches. That's only 50K
> lines. Passing that data (channel - it came in over a socket) down to C, I
> got it to run in 0.3 seconds on the same hardware, doing essentially the
> exact same operations (i.e. we parsed the exact same data stream into the
> exact same resulting data in C). You can figure out the speedup.
Are you aware of this Thread here in c.l.tcl: "Tcl faster than
Perl/Python...but only with tricks..."
(http://groups.google.de/group/comp....24b34cbdc392162)
I and some others posted some Tcl tricks that makes parsing lines with
matching a regexp extremely fast. Maybe, its of use for you, my best
solution was here (Tcl faster than Perl/Python...but only with tricks...).
It reads 117154 lines (8.2 MB) in 0.22 seconds and does a regexp-match on
each line. Can't replace your current C solution, as its already there, but
may help you for future problems:
---
proc grep {} {
set f [open bigfile r]
while { [set chunk [read $f 65536]] != "" } {
if {[string index $chunk end] != "\n" } {
append chunk [gets $f] "\n"
}
puts -nonewline [join
[regexp -all -inline -linestop -nocase .*destroy.*\n} $chunk] {}]
}
}
---
Regards
Stephan
| |
| Stephan Kuhagen 2007-02-21, 4:10 am |
| MH wrote:
> Yup, followed this thread. The 0.22 seconds is a very machine-specific
> time - it doesn't compare to our environment (NFS servers, VNC clients,
> etc). It may well be 2.2 seconds on our machines. Or 1.1.
Of course. The 0.22 is just there to show the possible speedup. Overhead by
other factors always add to all solutions. NFS does not only slow my
version down, but also a pure C implementation. The question is, how fast
you can get without the other bottlenecks, because they apply to any
solution. However, the script example should not be a full solution for
your problem, just a suggestion how to get some things fast, where the
straight forward approach is very slow in Tcl.
> Also, we need to extract 5-10 fields from each line, not just grep for a
> given string. And even then, we'd need to call the C/C++ backend for each
> one of the 50K lines (i.e. 50K C calls instead of one!).
>
> I do appreciate your helpful thinking. However, in our case, I'm pretty
> sure it's a non-starter.
Maybe not, but maybe for another similar problem in the future, where some
calls to C backends are not mandatory but only a choice of implementation,
when you think, Tcl would be too slow, but isn't necessarily.
Regards
Stephan
| |
|
| In article <ergu0a$p60$1@kohl.informatik.uni-bremen.de>,
Stephan Kuhagen <nospam@domain.tld> wrote:
>MH wrote:
>
>
>Of course. The 0.22 is just there to show the possible speedup. Overhead by
>other factors always add to all solutions. NFS does not only slow my
>version down, but also a pure C implementation. The question is, how fast
>you can get without the other bottlenecks, because they apply to any
>solution. However, the script example should not be a full solution for
>your problem, just a suggestion how to get some things fast, where the
>straight forward approach is very slow in Tcl.
>
>
>Maybe not, but maybe for another similar problem in the future, where some
>calls to C backends are not mandatory but only a choice of implementation,
>when you think, Tcl would be too slow, but isn't necessarily.
I code mostly in Tcl, and realize it's not slow. I was just pointing out
that in some cases, Tcl simply is NOT competitive. I'm happy to use Tcl for
the most part. In my time here, I've written probably 15K+ lines of Tcl, and
10K lines of C/C++.
MH
| |
| Donal K. Fellows 2007-02-22, 4:19 am |
| MH wrote:
> I code mostly in Tcl, and realize it's not slow. I was just pointing out
> that in some cases, Tcl simply is NOT competitive.
Occasionally, a task is really computationally heavy. There are
languages that specialize in dealing with such things; Tcl isn't one
of them. (One of) Tcl's strength(s) is how it can integrate heavy-
lifting components in other languages together into a whole
application. Using another language for components isn't bad, it's The
Tcl Way!
Donal.
|
|
|
|
|