Slight Rebol performace comparison ...
[1/11] from: petr::krenzelok::trz::cz at: 11-Jun-2001 23:56
Hi,
not much of an issue, just kind of competitive joking around performance
with my colleague at my work. He was asked to filter some 1.4 MB text file,
so he created native utility using Visual Objects. He was amazed that
resulting file was generated in some two or three secs, and told me: "Hey,
now try to do it in your famous Rebol, it will last years".
So I hacked very short scripts (just opening direct source and target ports
in line mode), and was interested, if I can run under 5 to 7 secs on the
same machine. The result was, however, a little bit surprising - 1 sec!
I know we can't compare, as both environment used different conditions. I
think that because of progress bar (and so GUI classes), VO app called
myriad of .dlls scattere over the hd :-) But hey, anyway, the speed of
interpreted
language surprised us both :-)
So ... :-)
-pekr-
[2/11] from: ryanc:iesco-dms at: 11-Jun-2001 16:11
Great story Petr!
Petr Krenzelok wrote:
> Hi,
> not much of an issue, just kind of competitive joking around performance
<<quoted lines omitted: 15>>
> [rebol-request--rebol--com] with "unsubscribe" in the
> subject, without the quotes.
--
Ryan Cole
Programmer Analyst
www.iesco-dms.com
707-468-5400
I am enough of an artist to draw freely upon my imagination.
Imagination is more important than knowledge. Knowledge is
limited. Imagination encircles the world.
-Einstein
[3/11] from: petr:krenzelok:trz:cz at: 12-Jun-2001 12:41
Ryan Cole wrote:
> Great story Petr!
I copied/appended test source today to some final size of 21 MB and was
interested in performance tests once again:
VO code - 38 sec
Rebol code - 35 sec (rebol start not measured, but Rebol still nicely compares to
compiled language (VO uses native code - no p-code))
Cheers,
-pekr-
[4/11] from: gjones05:mail:orion at: 12-Jun-2001 6:13
From: "Petr Krenzelok"
> I copied/appended test source today to some final size of 21 MB and was
> interested in performance tests once again:
>
> VO code - 38 sec
> Rebol code - 35 sec (rebol start not measured, but Rebol still nicely compares
to
> compiled language (VO uses native code - no p-code))
Wow! RT clearly has optimized some important places at the native level of
code.
--Scott Jones
[5/11] from: robert:muench:robertmuench at: 12-Jun-2001 19:39
> -----Original Message-----
> From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On Behalf
<<quoted lines omitted: 5>>
> with my colleague at my work. He was asked to filter some 1.4 MB text file,
> so he created native utility using Visual Objects.
Hi, just want to report a cool script I hacked today to handle 155 MB (!!) of
semicolon seperated text data in less than 4 minutes. My colleague tried it with
MS access (ROFL) for more than 30 minutes and than I helped him... :-)) The
open/direct/lines stuff is really a cool thing for slicing tons of data. Robert
[6/11] from: rsaathoff:datajunction at: 12-Jun-2001 12:55
----- Original Message -----
From: "Robert M. Muench" <[robert--muench--robertmuench--de]>
To: <[rebol-list--rebol--com]>
Sent: Tuesday, June 12, 2001 12:39 PM
Subject: [REBOL] Re: Slight Rebol performace comparison ...
> > -----Original Message-----
> > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On Behalf
<<quoted lines omitted: 4>>
> > not much of an issue, just kind of competitive joking around performance
> > with my colleague at my work. He was asked to filter some 1.4 MB text
file,
> > so he created native utility using Visual Objects.
>
> Hi, just want to report a cool script I hacked today to handle 155 MB (!!)
of
> semicolon seperated text data in less than 4 minutes. My colleague tried
it with
> MS access (ROFL) for more than 30 minutes and than I helped him... :-))
The
> open/direct/lines stuff is really a cool thing for slicing tons of data.
Robert
Any chance you'll upload the script for the rest of us to see?? ;)
(kidding...)
Ryan
[7/11] from: joel:neely:fedex at: 13-Jun-2001 1:53
Hi, Petr,
Just one quick observation...
Petr Krenzelok wrote:
> Ryan Cole wrote:
> > Great story Petr!
<<quoted lines omitted: 4>>
> still nicely compares to compiled language (VO uses native
> code - no p-code))
Based on some benchmarking I did a couple of years ago (in
Java, if anyone was curious) the performance consequencess of
different I/O buffering schemes (i.e., character-at-a-time,
line-at-a-time, big-buffer-at-a-time, or all-input-at-once)
can easily dominate total run time, swamping any performance
gains from compilation vs. interpretation for file-oriented
(non-compute-bound) processes.
We know what REBOl does about
my-file-data: read %somefile.data
but do you know what type of I/O scheme your collegue's VO
program was using?
-jn-
------------------------------------------------------------
Programming languages: compact, powerful, simple ...
Pick any two!
joel'dot'neely'at'fedex'dot'com
[8/11] from: petr:krenzelok:trz:cz at: 13-Jun-2001 9:37
Joel Neely wrote:
> Hi, Petr,
> Just one quick observation...
<<quoted lines omitted: 23>>
> but do you know what type of I/O scheme your collegue's VO
> program was using?
:-)
METHOD Start() CLASS App
LOCAL path,cTemp AS STRING
LOCAL fFil AS PTR
LOCAL fVys AS PTR
Zprava(,"Pracuje se na tom","Necum","X",FALSE)
path:=WorkDir()
IF (fVys:=FCreate("vystup.txt",FC_NORMAL))<>F_ERROR
IF (fFil:=FOpen("pokus.txt",FO_READ))<>F_ERROR
DO WHILE !FEof(fFil)
cTemp:=FReadLine(fFil)
IF Len(AllTrim(cTemp))<>0 .and. Left(cTEmp,5)<>"NAZEM" .and.
Left(cTEmp,5)<>"=====" .and. Left(cTEmp,1)<>CHR(12)
// zapsat radek
FWriteLine(fVys,cTemp)
ENDIF
ENDDO
ENDIF
ENDIF
TextYes(,"Prace dokoncena.")
SELF:quit()
As you can see, VO provides low level enough file handling functions
.... The question is, what does FReadLine does, but on the other hand
Rebol, even when /direct is used, reads some data into port/state/buffer
...
My code follows:
REBOL []
start: now/time
zdroj: open/direct/lines %pokus.txt
cil: open/direct/lines %vyslx.txt
while [line: copy/part zdroj 1][
tmp: copy/part first line 5
if all [(not empty? trim/all copy first line) (tmp <> "NAZEM") (tmp <>
=====
) ((to-char first tmp) <> (to-char 12))][
insert tail cil first line
]
]
close cil
close zdroj
write %time.log now/time - start
-pekr-
[9/11] from: g:santilli:tiscalinet:it at: 13-Jun-2001 19:17
Hello Joel!
On 13-Giu-01, you wrote:
JN> but do you know what type of I/O scheme your collegue's VO
JN> program was using?
I think this is the problem, Joel. Other languages tend to be so
much more complicated that the programmer usually does not care
about this kind of details. Also, sometimes you're just using a
component written by some guy at a certain big (the countrary of
micro) software corporation who believed to be smarter than you
and decided what you need and what you don't.
REBOL's simplicity makes REBOL programs MUCH better than other
programs, unless we're talking about hand-crafted pure-C code
written by people like Carl, Holger, Jeff or Sterling. ;-)
Regards,
Gabriele.
--
Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer
Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/
[10/11] from: joel:neely:fedex at: 13-Jun-2001 14:32
Hi, Gabriele,
Gabriele Santilli wrote:
> I think this is the problem, Joel. Other languages tend to be so
> much more complicated that the programmer usually does not care
> about this kind of details.
>
That wasn't my experience. Changing the buffering discipline for
the tests I mentioned earlier required altering only a couple of
lines of code.
> REBOL's simplicity makes REBOL programs MUCH better than other
> programs...
>
It's not possible for me to talk about "better" unless I know what
yardstick we're using. Run time? Development time? Ease of
maintenance? TCO (including training and learning curve for new
people being added to a project, and the availability of resources
for their learning)? Aesthetics? Access to existing libraries
that do parts of the task at hand "well enough"? (and the list
goes on and on...)
--
___ ___ ___
\/ 2 + \/ 2 = 4 (for sufficiently large approximations of \/ 2 )
joel'dot'neely'at'fedex'dot'com
[11/11] from: g:santilli:tiscalinet:it at: 14-Jun-2001 19:38
Hello Joel!
On 13-Giu-01, you wrote:
JN>> I think this is the problem, Joel. Other languages tend to
JN>> be so much more complicated that the programmer usually does
JN>> not care about this kind of details.
JN> That wasn't my experience. Changing the buffering discipline
JN> for the tests I mentioned earlier required altering only a
JN> couple of lines of code.
Well, certainly it depends a lot on the languages and on the
libraries you are using. Or better, maybe I should say it's a
matter of the environment you are using. Sometimes there are so
much layers, that you can't even guess what's really going on.
Also, I'm sure most of the people on this list would write very
good code in any language. It's just that REBOL makes people think
in different terms, and makes them writing better (simpler) code.
JN> It's not possible for me to talk about "better" unless I know
JN> what yardstick we're using. Run time? Development time? Ease
[...]
You're absolutely right. I think I usually mean "more elegant,
simpler" when I say "better". Simpler means that you have complete
control on it; more elegant means that it is more readable,
smaller and faster, and that it has been written with some
thought.
Regards,
Gabriele.
--
Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer
Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted