Rebol API to DyBASE
[1/27] from: knizhnik:garret:ru at: 17-Dec-2003 14:15
Hello all,
First version of Rebol API to my object-oriented database DyBASE is
ready. It can be downloaded from my site:
http://www.garret.ru/~knizhnik/dybase.html
DyBASE is embedded object oriented database for languages with dynamic
type checking. Rebol is fourth language for which DyBASE API is
provided. Data in database is stored in language independent format,
so (with some exceptions) data written by Python application can be
accessed by Rebol application (and visa versa).
Please read Rebol section in DyBYSE manual to get more information of
about specific of Rebol interface to DyBASE.
To use DyBASE at Windows in your Rebol application you need to include in PATH
two libraries: DyBASE core dybasedll.dll (which is located in dybase\lib
directory) and Rebol wrapper - dybaseapi.dll (located in dybase\rebol
directory). At Unix you should first build these libraries. Use
makefile in dybase/src and dybase/rebol directories.
Then just load "dybase.r" module.
Please look also at examples:
dybase/rebol/guess.r - game: "guess an animal"
dybase/rebol/testindex.r - test of indices
dybase/rebol/testlink.r - detail-order-supplier database
All bug reports, change requests, suggestions are welcome.
--
Best regards,
Konstantin mailto:[knizhnik--garret--ru]
[2/27] from: antonr:iinet:au at: 18-Dec-2003 2:05
Hmm looks interesting.
I have downloaded it and looked quickly but
I must go to bed...
Anton.
[3/27] from: knizhnik:garret:ru at: 17-Dec-2003 18:55
Hello Cyphre,
Wednesday, December 17, 2003, 6:40:03 PM, you wrote:
C> Hi,
C> I just had a quick look at
C> http://www.garret.ru/~knizhnik/dybase/doc/dybase.html#comparison . Is Rebol
C> really so slow or it is because the ported code isn't optimized to the
C> language yet?
Rebol has awful implementation of hash tables.
First of all, it is very inconvenient that there are normal set/get
operations. You have to use something like this:
h: find/tail hash key
either h [change h key value] [append append hash key value]
instead of
hash[key] = value
in most other high-level languages.
And as far as Rebol hash is also series, appending element to it cause
a lot of reallocations, so complexity of insert operation seems to be
linear (instead of constant). And if we use "insert hash" instead of
append hash
(not "insert tail hash"), then performance becomes
really awful - copying all series element increase complexity to
quadratic and insertion of 100000 integer elements in hash takes about
half an hour (less then second in all other languages).
And as far as object cache is one of the main components of object
oriented database, such inefficient implementation of hash table leads
to poor performance of Rebol DyBASE API.
C> regards
C> Cyphre
C> ----- Original Message -----
C> From: "Konstantin Knizhnik" <[knizhnik--garret--ru]>
C> To: <[rebol-list--rebol--com]>
C> Sent: Wednesday, December 17, 2003 12:15 PM
C> Subject: [REBOL] Rebol API to DyBASE
>>
>> Hello all,
<<quoted lines omitted: 13>>
>>
>> To use DyBASE at Windows in your Rebol application you need to include in
C> PATH
>> two libraries: DyBASE core dybasedll.dll (which is located in dybase\lib
>> directory) and Rebol wrapper - dybaseapi.dll (located in dybase\rebol
<<quoted lines omitted: 19>>
>>
>>
--
Best regards,
Konstantin mailto:[knizhnik--garret--ru]
[4/27] from: knizhnik:garret:ru at: 17-Dec-2003 19:14
Hello Cyphre,
Wednesday, December 17, 2003, 6:40:03 PM, you wrote:
C> Hi,
C> I just had a quick look at
C> http://www.garret.ru/~knizhnik/dybase/doc/dybase.html#comparison . Is Rebol
C> really so slow or it is because the ported code isn't optimized to the
C> language yet?
Compare the following results:
Rebol: 18 seconds
h: make hash! []
start: now/time
n: 100000
for i 1 n 1 [
append h i
]
print ["Elapsed time for" n "records" (now/time - start)]
-----------------------
Python: 0.37 seconds
import time
d = {}
start = time.time()
for i in range(0,100000):
d[i] = i
print 'Elapsed time: ', time.time() - start, ' seconds'
--------------------
PHP: 1 seconds (rounded)
<?php
$start = time();
$arr = array();
for ($i = 0; $i < 10000; $i++) {
$arr[$i] = $i;
}
print("Elapsed time: " . (time() - $start) . " seconds\n");
?>
C> regards
C> Cyphre
C> ----- Original Message -----
C> From: "Konstantin Knizhnik" <[knizhnik--garret--ru]>
C> To: <[rebol-list--rebol--com]>
C> Sent: Wednesday, December 17, 2003 12:15 PM
C> Subject: [REBOL] Rebol API to DyBASE
>>
>> Hello all,
<<quoted lines omitted: 13>>
>>
>> To use DyBASE at Windows in your Rebol application you need to include in
C> PATH
>> two libraries: DyBASE core dybasedll.dll (which is located in dybase\lib
>> directory) and Rebol wrapper - dybaseapi.dll (located in dybase\rebol
<<quoted lines omitted: 19>>
>>
>>
--
Best regards,
Konstantin mailto:[knizhnik--garret--ru]
[5/27] from: greggirwin:mindspring at: 17-Dec-2003 9:26
Hi Konstantin,
First, thanks for completing the REBOL interface to DyBase!
Now, if all the source to it is available, any good folks here who
want to take a crack at improving can do so, right? Hopefully, we can
give you some helpful feedback, in return for all your work.
Thanks again!
-- Gregg
[6/27] from: knizhnik:garret:ru at: 17-Dec-2003 19:30
Hello Konstantin,
Wednesday, December 17, 2003, 7:14:02 PM, you wrote:
KK> Hello Cyphre,
KK> Wednesday, December 17, 2003, 6:40:03 PM, you wrote:
C>> Hi,
C>> I just had a quick look at
C>> http://www.garret.ru/~knizhnik/dybase/doc/dybase.html#comparison . Is Rebol
C>> really so slow or it is because the ported code isn't optimized to the
C>> language yet?
KK> Compare the following results:
KK> Rebol: 18 seconds
KK> h: make hash! []
KK> start: now/time
KK> n: 100000
KK> for i 1 n 1 [
KK> append h i
KK> ]
KK> print ["Elapsed time for" n "records" (now/time - start)]
KK> -----------------------
KK> Python: 0.37 seconds
KK> import time
KK> d = {}
KK> start = time.time()
KK> for i in range(0,100000):
KK> d[i] = i
KK> print 'Elapsed time: ', time.time() - start, ' seconds'
KK> --------------------
KK> PHP: 1 seconds (rounded)
KK> <?php
KK> $start = time();
KK> $arr = array();
KK> for ($i = 0; $i < 10000; $i++) {
KK> $arr[$i] = $i;
KK> }
KK> print("Elapsed time: " . (time() - $start) . " seconds\n");
?>>
It was mistyping in PHP script - 10000 instead of 100000.
But with 100000 iterations reported time was the same - 1 second.
And if remove assignment to hash table and use just empty loop body
(pure speed of interpreter), then times for 10000000 (ten millions)
iteration are
Python: 14 seconds
PHP: 17 seconds
Rebol: 58 seconds
Also bad result (for Rebol), but 3 times slower is not 50 times slower...
--
Best regards,
Konstantin mailto:[knizhnik--garret--ru]
[7/27] from: petr:krenzelok:trz:cz at: 17-Dec-2003 16:39
Anton Rolls wrote:
>Hmm looks interesting.
>I have downloaded it and looked quickly but
>I must go to bed...
>
you don't have to - just dring more coffee :-)
-pekr-
[8/27] from: cyphre:seznam:cz at: 17-Dec-2003 16:40
Hi,
I just had a quick look at
http://www.garret.ru/~knizhnik/dybase/doc/dybase.html#comparison . Is Rebol
really so slow or it is because the ported code isn't optimized to the
language yet?
regards
Cyphre
[9/27] from: knizhnik:garret:ru at: 17-Dec-2003 19:44
Hello Gregg,
Wednesday, December 17, 2003, 7:26:41 PM, you wrote:
GI> Hi Konstantin,
GI> First, thanks for completing the REBOL interface to DyBase!
GI> Now, if all the source to it is available, any good folks here who
GI> want to take a crack at improving can do so, right? Hopefully, we can
GI> give you some helpful feedback, in return for all your work.
Certainly, all sources are available.
And I will be glad to receive any improvements.
I only want to notice, that I want to use universal database format
for all languages. So I will not include in DyBASE features which are
not present in other languages. Certainly anyone can create its own
version of DyBASE based on my implementation and I have nothing
against it. But I will include in my distribution only those changes which
I consider to be useful.
GI> Thanks again!
GI> -- Gregg
--
Best regards,
Konstantin mailto:[knizhnik--garret--ru]
[10/27] from: chris:langreiter at: 17-Dec-2003 17:48
> Compare the following results:
> Rebol: 18 seconds
h: make hash! 100000
start: now/time/precise
for i 1 100000 1 [ insert tail h i ]
now/time/precise - start
== 0:00:00.25
That's 250 msec. Your version runs in about 350 msec.
Since I can't imagine you're running a machine 50 times slower than
mine, there's something seriously weird going on ...
BTW, I still don't quite get why append has to be so much slower than
insert tail. Does anyone have any ideas wrt/ that issue?
[11/27] from: tim:johnsons-web at: 17-Dec-2003 8:01
* Konstantin Knizhnik <[knizhnik--garret--ru]> [031217 07:26]:
> Rebol has awful implementation of hash tables.
> First of all, it is very inconvenient that there are normal set/get
<<quoted lines omitted: 3>>
> instead of
> hash[key] = value
Grrr! I *hate* doing that, and in python I have to do
it a lot!
In rebol, I just do
hash/que 'val key
much nicer, it took me half a day to implement
my own object, but it was well worth it.
> in most other high-level languages.
>
> And as far as Rebol hash is also series, appending element to it cause
Hmm! Are you not using to-hash ?
> a lot of reallocations, so complexity of insert operation seems to be
> linear (instead of constant). And if we use "insert hash" instead of
> "append hash" (not "insert tail hash"), then performance becomes
> really awful - copying all series element increase complexity to
> quadratic and insertion of 100000 integer elements in hash takes about
> half an hour (less then second in all other languages).
I haven't run tests like that, but see my comment above.
> And as far as object cache is one of the main components of object
> oriented database, such inefficient implementation of hash table leads
> to poor performance of Rebol DyBASE API.
All language have their strengths and weaknesses, *and* their "best
fits".
Mysql is a best fit for rebol IMHO, rebol mysql access on our large,
multi-language projects beats perl and python hands down both
in access speed and in impelementation/coding. One of Rebol's strengths
is TCP/IP is native (compiled into the binray)
and the mysql-protocol exploits that splendidly.
On the other hand, perhaps the native 'hash' of rebol is not is
advanced as the btree approach that python uses.
I do believe that a true hash datatype is a linked list,
though.
still, it is nice to see these tests and the work that you've
done.
regards
tim
> C> regards
> C> Cyphre
<<quoted lines omitted: 50>>
> To unsubscribe from this list, just send an email to
> [rebol-request--rebol--com] with unsubscribe as the subject.
--
Tim Johnson <[tim--johnsons-web--com]>
http://www.alaska-internet-solutions.com
[12/27] from: chris:langreiter at: 17-Dec-2003 18:13
#Bonjour Konstantin,
Wednesday, December 17, 2003, 5:30:08 PM, you wrote:
> Hello Konstantin,
> Wednesday, December 17, 2003, 7:14:02 PM, you wrote:
KK>> Hello Cyphre,
KK>> Wednesday, December 17, 2003, 6:40:03 PM, you wrote:
C>>> Hi,
C>>> I just had a quick look at
C>>> http://www.garret.ru/~knizhnik/dybase/doc/dybase.html#comparison . Is Rebol
C>>> really so slow or it is because the ported code isn't optimized to the
C>>> language yet?
KK>> Compare the following results:
KK>> Rebol: 18 seconds
KK>> h: make hash! []
KK>> start: now/time
KK>> n: 100000
KK>> for i 1 n 1 [
KK>> append h i
KK>> ]
KK>> print ["Elapsed time for" n "records" (now/time - start)]
KK>> -----------------------
KK>> Python: 0.37 seconds
KK>> import time
KK>> d = {}
KK>> start = time.time()
KK>> for i in range(0,100000):
KK>> d[i] = i
KK>> print 'Elapsed time: ', time.time() - start, ' seconds'
KK>> --------------------
KK>> PHP: 1 seconds (rounded)
KK>> <?php
KK>> $start = time();
KK>> $arr = array();
KK>> for ($i = 0; $i < 10000; $i++) {
KK>> $arr[$i] = $i;
KK>> }
KK>> print("Elapsed time: " . (time() - $start) . " seconds\n");
?>>>
> It was mistyping in PHP script - 10000 instead of 100000.
> But with 100000 iterations reported time was the same - 1 second.
<<quoted lines omitted: 5>>
> Rebol: 58 seconds
> Also bad result (for Rebol), but 3 times slower is not 50 times slower...
That's probably because 'for is written in REBOL (enter "?? for") ;-)
start: now/time/precise
i: 0
loop 10000000 [ i: i + 1 ]
start - now/time/precise
takes only 3.5 secs.
[13/27] from: greggirwin:mindspring at: 17-Dec-2003 10:23
Hi Konstantin,
KK> Compare the following results:
KK> Rebol: 18 seconds
I get ~.86-.93 seconds on my P900/W2K/View-1.2.10 here for your first
test.
What do you get for this one? (I get ~.50-.56 sec for this one using
hash! and ~.36-.37 using list! -- ~.56-.58 and ~.48-.50 without
preallocating space)
n: 100'000
h: make hash! n ; []
start: now/time/precise
repeat i n [append h i]
print ["Elapsed time for" n "records" (now/time/precise - start)]
FOR is a mezzanine function, so it is *much* slower than native
looping functions like REPEAT.
KK> And if remove assignment to hash table and use just empty loop body
KK> (pure speed of interpreter), then times for 10000000 (ten millions)
KK> iteration are
KK>
KK> Python: 14 seconds
KK> PHP: 17 seconds
KK> Rebol: 58 seconds
I get ~.34-.38 here, using REPEAT. Using LOOP I get ~.31.
n: 10'000'000
start: now/time/precise
loop n []
print ["Elapsed time for" n "records" (now/time/precise - start)]
I haven't looked at your DyBase interface yet, but the list! datatype
in REBOL is more suited to many inserts and removals, when compared
with hash! or block! values. You may want the hash! for lookup speed
I'm guessing though.
-- Gregg
[14/27] from: knizhnik:garret:ru at: 17-Dec-2003 20:24
Hello Christian,
Wednesday, December 17, 2003, 7:48:54 PM, you wrote:
>> Compare the following results:
>> Rebol: 18 seconds
CL> h: make hash! 100000
CL> start: now/time/precise
CL> for i 1 100000 1 [ insert tail h i ]
CL> now/time/precise - start
CL> == 0:00:00.25
O, shame on me - I have to guess myself that preallocating hash size
will have such effect. with "make hash! 100000" instead of just
make hash! []
, results at my computer are:
1.1983 seconds with append, 1.151 with "insert tail"
The only justification for my fault is that in ALL other languages I
know, omitting initial hash size parameter has no such dramatical
influence on performance (usually hash size is doubled)
CL> That's 250 msec. Your version runs in about 350 msec.
CL> Since I can't imagine you're running a machine 50 times slower than
CL> mine, there's something seriously weird going on ...
CL> BTW, I still don't quite get why append has to be so much slower than
CL> insert tail. Does anyone have any ideas wrt/ that issue?
It is clear - append is implemented using insert:
append: func [
{Appends a value to the tail of a series and returns the series head.}
series [series! port!]
value
/only "Appends a block value as a block"
][
head either only [
insert/only tail series :value
] [
insert tail series :value
]
]
--
Best regards,
Konstantin mailto:[knizhnik--garret--ru]
[15/27] from: greggirwin:mindspring at: 17-Dec-2003 10:26
Hi Konstantin,
KK> I only want to notice, that I want to use universal database format
KK> for all languages. So I will not include in DyBASE features which are
KK> not present in other languages. Certainly anyone can create its own
KK> version of DyBASE based on my implementation and I have nothing
KK> against it. But I will include in my distribution only those changes which
KK> I consider to be useful.
That makes sense. I think sticking with your standard interface, and
seeing if we can speed it up, it the best place to start.
-- Gregg
[16/27] from: joel:neely:fedex at: 17-Dec-2003 11:25
Hi, Konstantin,
Maybe even worse?
Konstantin Knizhnik wrote:
> And as far as Rebol hash is also series, appending element to it
> cause a lot of reallocations, so complexity of insert operation
<<quoted lines omitted: 4>>
> elements in hash takes about half an hour (less then second in all
> other languages).
INSERTs into a "fresh" hash (created each time with MAKE HASH! []):
Appears to be increasing faster than quadratically!
# elts seconds ratio quad slowdown
10000 3.065
20000 25.817 8.423 4 2.106
30000 63.682 20.777 9 2.309
40000 123.417 40.267 16 2.517
APPENDs into a "growing" hash (not reconstructed between runs):
# elts seconds
40000 2.153
40000 6.69
40000 10.956
40000 15.453
40000 19.568
Here the number of appends in each stest is the same, but the time
complexity of managing a growing structure shows up; likewise, for
a simple block:
APPENDs into a "growing" block:
# elts seconds
40000 2.073
40000 6.529
40000 10.735
40000 14.962
40000 18.907
If we take out the reallocation-for-growth issues we get these:
APPENDs into a "growing" hash initialized with MAKE HASH! 200000
# elts seconds
40000 0.22
40000 0.251
40000 0.2
40000 0.33
40000 0.281
APPENDs into a "growing" block initialized with MAKE BLOCK! 200000
# elts seconds
40000 0.17
40000 0.17
40000 0.171
40000 0.191
40000 0.171
Preallocation of space (whenever possible ;-) is our friend!
-jn-
--
----------------------------------------------------------------------
Joel Neely joelDOTneelyATfedexDOTcom 901-263-4446
Enron Accountingg in a Nutshell: 1c=$0.01=($0.10)**2=(10c)**2=100c=$1
[17/27] from: didec:tiscali at: 17-Dec-2003 19:25
Re: Rebol API to DyBASE
Just to say that "Introduction" on your web page doesn't mention Rebol at this time (first
paragraph).
http://www.garret.ru/~knizhnik/dybase/doc/dybase.html#introduction
I'm prety sure you have just forgoten to add it.
If time let me test your work, I will be happy to do so.
Regards
Didier
[18/27] from: greggirwin:mindspring at: 17-Dec-2003 10:39
Hi Konstantin,
I should mention that list! values operate a little differently than
hash!/block! values, should you decide to try it out.
With a list!:
INSERT modifies list to just after the point of insertion.
REMOVE-ing the element currently referenced in a list sets
the list to its tail.
-- Gregg
[19/27] from: knizhnik:garret:ru at: 17-Dec-2003 20:39
Hello Tim,
Wednesday, December 17, 2003, 8:01:14 PM, you wrote:
TJ> * Konstantin Knizhnik <[knizhnik--garret--ru]> [031217 07:26]:
>>
>>
<<quoted lines omitted: 8>>
>>
>> hash[key] = value
TJ> Grrr! I *hate* doing that, and in python I have to do
TJ> it a lot!
TJ> In rebol, I just do
TJ> hash/que 'val key
TJ> much nicer, it took me half a day to implement
TJ> my own object, but it was well worth it.
Do not forget to say "from my point of view..."
I think that a lot of other people will consider "hash[key] = value"
syntax much clearer and simpler than "hash/que 'val key".
But it is a matter of taste and so can not be discussed - somebody like
red color, somebody - black. It is waste of time to discuss which
color is better. In Python you can also define your own class and do
everything you like in it. But associative array (dictionary, hash
table) is fundamental data structure and if high level language has
no such builtin or standard library structure - it is not advantage of
this language.
>> in most other high-level languages.
TJ> All language have their strengths and weaknesses, *and* their "best
TJ> fits".
Yes, all attempts to create some "best" universal language are
failed. Each language has its own advantages and its own domain.
TJ> Mysql is a best fit for rebol IMHO, rebol mysql access on our large,
TJ> multi-language projects beats perl and python hands down both
TJ> in access speed and in impelementation/coding.
MySQL is certainly best solution when you are implementing some server
application. But even in this case DyBASE has some advantages:
- efficient transaction mechanism
- transparent object loading and storing (I hope you do will not say that
packing/unpacking data from relational database is "nicer" than...
lack of packing/unpacking).
But DyBASE is positioned for another kind of applications - which
needs embedded database engine. If your application needs to store
some data between sessions, you will not include MySQL in
distribution, will you? And require user to setup, configure and
administrate it.
So, as well as programming languages, DyBASE has its own niche.
TJ> One of Rebol's strengths
TJ> is TCP/IP is native (compiled into the binray)
TJ> and the mysql-protocol exploits that splendidly.
Hmm, and in which language TCP/IP is not native?
All of them sooner or later will have to invoke system OS function to access sockets,...
TJ> On the other hand, perhaps the native 'hash' of rebol is not is
TJ> advanced as the btree approach that python uses.
TJ> I do believe that a true hash datatype is a linked list,
TJ> though.
TJ> still, it is nice to see these tests and the work that you've
TJ> done.
TJ> regards
TJ> tim
--
Best regards,
Konstantin mailto:[knizhnik--garret--ru]
[20/27] from: robert:muench:robertmuench at: 17-Dec-2003 23:39
On Wed, 17 Dec 2003 14:15:57 +0300, Konstantin Knizhnik
<[knizhnik--garret--ru]> wrote:
> First version of Rebol API to my object-oriented database DyBASE is
> ready. It can be downloaded from my site:
> http://www.garret.ru/~knizhnik/dybase.html
Hi, even I'm in close private contact with you about DyBASE, I want to
thank you here on the mailinglist for the Rebol API work you have done.
For the others, I contacted Konstantin some weeks ago about a Rebol API.
And he hadn't touched the language before.
As I told you already, I'm quite impressed about your work. With DyBASE we
have the first embedded database engine for Rebol. IMO such a thing can
make application development with Rebol much easier. When using the SDK,
it's now possible to develop quite complex database stuff in a compact
environment.
I know that you are not a big fan of Rebol (yet) and that you have some
criticism about it. I don't want to start a "best-language" discussion
here. The API and everything is provided, so I ask the members of the list
to have a look and see how far we can help to optimize the DyBASE
implementation. IMO it can't hold, that the Rebol version is the slowest
;-))
--
Robert M. Münch
Management & IT Freelancer
Mobile: +49 (177) 245 2802
http://www.robertmuench.de
[21/27] from: tim:johnsons-web at: 17-Dec-2003 17:31
* Konstantin Knizhnik <[knizhnik--garret--ru]> [031217 10:40]:
> Hello Tim,
> Wednesday, December 17, 2003, 8:01:14 PM, you wrote:
<<quoted lines omitted: 13>>
> TJ> my own object, but it was well worth it.
> Do not forget to say "from my point of view..."
always my point of view...
> I think that a lot of other people will consider "hash[key] = value"
> syntax much clearer and simpler than "hash/que 'val key".
I implement parallel systems in python and rebol, data-structure
driven schemes for building dynamic forms that read and write
databases... and there's a hell of a lot less quoting in
rebol than in python. That's more important to me... And there's
also a lot less general coding in rebol than in python.
*but* I find the python scales better. For me. And I like a
lot of python OOP techniques. I love them both!
> But it is a matter of taste and so can not be discussed - somebody like
>
> >> in most other high-level languages.
>
> TJ> All language have their strengths and weaknesses, *and* their "best
> TJ> fits".
>
> Yes, all attempts to create some "best" universal language are
> failed. Each language has its own advantages and its own domain.
Not only that, but the customer or the nature of the customer
can dictate the language...
> TJ> Mysql is a best fit for rebol IMHO, rebol mysql access on our large,
> TJ> multi-language projects beats perl and python hands down both
<<quoted lines omitted: 14>>
> TJ> and the mysql-protocol exploits that splendidly.
> Hmm, and in which language TCP/IP is not native?
Read this again:
> TJ> is TCP/IP is native (compiled into the binray)
This is the second thread that I've seen in a week, in which
someone without an in-depth knowledge of rebol coding techniques
has introduced themselves to this list by making criticisms
of rebol. I make a living, not by being a brilliant programmer,
but by providing a good product. That's the bottom line.
If I were introduce a product of mine to say the python or
the perl community, I would not begin by criticizing the target
language. It would be counter-productive of my goals....
'nuf said on this topic, I'll check out your stuff to see
what sort of 'fit' it has for my python or my rebol systems.
Good thread..
tj
--
Tim Johnson <[tim--johnsons-web--com]>
http://www.alaska-internet-solutions.com
[22/27] from: g:santilli:tiscalinet:it at: 18-Dec-2003 11:02
Hi Konstantin,
On Wednesday, December 17, 2003, 5:14:02 PM, you wrote:
KK> Rebol: 18 seconds
KK> h: make hash! []
KK> start: now/time
KK> n: 100000
KK> for i 1 n 1 [
KK> append h i
KK> ]
KK> print ["Elapsed time for" n "records" (now/time - start)]
>> h: make hash! 100002
== make hash! []
>> start: now/time/precise repeat i 100000 [insert tail h i] print now/time/precise -
start
0:00:00.121
Do I have such a faster computer here? ;-)
Regards,
Gabriele.
--
Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer
Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/
[23/27] from: knizhnik:garret:ru at: 18-Dec-2003 14:37
Thank you very much to all who helps me to improve
Rebol API to DyBASE.
I am sorry that somebody treat my concerns about hash tables
in Rebol as criticism of this language.
I already understand that "make hash! 100000" is much more efficient
than "make hash! []" and "loop N" is faster than "for 1 N 1".
Frankly speaking I do not think that it is my fault or dullness:
number of element which will be placed in hash table rarely can be
predicted and one of the rules of good language design is that
1. there should be no similar constructions doing the same thing
2. programmer should be able to predict complexity of one or another
operation. It is clear that function "power" is more expensive than
for example "*". But it is impossible to guess that "append" is less
efficient than "update tail" without having sources. Or that
func[x][x]
is 10!!! times faster than "func[x][return x]"!
So excuse me once again for "criticism" of your favorite language.
Rebol is really interesting language. I could not say that I love
everything in it, but I have programmed in more than 10 programming
languages and invent two my own, and I could not said that some
of them is "the best language in the world" - even in its category
(I even not speaking about best universal programming language).
Each language has its pro- and contra- and designer of the language has
to solve a lot of compromises.
I have receive a number of hints how to improve code:
- replace "append" with "insert tail",
- "to-logic" with "to logic!"
- "(x = 'a) or (x = 'b)" with "find [a b] x"
- if (first x) = #"_" with if #"_" = first x
- "do cls" with "get cls"
- "for i 1 N 1" with "repeat i N"
- "to-string" with "form"
- "if x [ if y .... ]" with "if all [x y]..."
- "func[x][return x]" with "func[x][x]"
I have applied all of them. Updated version of DyBASE API is uploaded
to my site: http://www.garret.ru/dybase.html
But... performance of testindex.r is almost not changed.
That is why I decide to follow one of the fundamental principals of
software development - optimize only those code which needs to be
optimized (code in which program spends most of the time).
That is why I need to profile the execution of the program.
Unfortunately I had no profiler, because I have no professional
version of Rebol. I will be very pleased if somebody has Rebol profiler
and can profile execution of testindex.r and send profiler dump to me.
Thanks in advance
Konstantin
--
Best regards,
Konstantin mailto:[knizhnik--garret--ru]
[24/27] from: g:santilli:tiscalinet:it at: 18-Dec-2003 13:06
Hi Konstantin,
On Thursday, December 18, 2003, 12:37:03 PM, you wrote:
KK> So excuse me once again for "criticism" of your favorite language.
IMHO, you don't have to ask for that. Criticism is welcome and can
help the language too. Just don't expect us to always agree on it.
;-)
(In particular, we know that there are problems in the
implementation, and pointing that out can help fixing them;
however, design issues are a different story. There's a very good
reason for anything in REBOL to have been designed as it is, and
we have learned this during all our time with REBOL. Carl
Sassenrath has spent a lot of time and though on designing this
language. Of course, design is always a compromise, so it can't be
perfect...)
Regards,
Gabriele.
--
Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer
Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/
[25/27] from: greggirwin:mindspring at: 18-Dec-2003 10:00
Hi Konstantin,
KK> I am sorry that somebody treat my concerns about hash tables
KK> in Rebol as criticism of this language.
Not to worry. We've been through many of these discussions before
ourselves. I'll second what Gabriele said.
-- Gregg
[26/27] from: gchiu:compkarori at: 24-Dec-2003 22:52
On Thu, 18 Dec 2003 14:37:03 +0300
Konstantin Knizhnik <[knizhnik--garret--ru]> wrote:
>That is why I need to profile the execution of the
>program.
Hi Konstantin,
This is great work that you're doing. We shouldn't look a
gift horse in the mouth!
>Unfortunately I had no profiler, because I have no
>professional
>version of Rebol. I will be very pleased if somebody has
>Rebol profiler
>and can profile execution of testindex.r and send
>profiler dump to me.
>
If you're looking for a version of Rebol that has Call
enabled, then see here:
http://www.rebol.net/projects/view1.3/downloads/
These are experimental versions that are being updated
every few days. Call is enabled in these for testing
purposes. I presume that they will time out eventually.
Also, the latest version adds something that may help in
profiling
Here is a little enhancement to help developers optimize
code: a stats function that returns the number of blocks,
values, and functions that have been evaluated.
stats/evals returns a block with three integer counters
stats/evals/clear clears the evaluation counters (and
returns the prior counters)
HTH.
Oh, are you planning on more extensive documentation?
--
Graham Chiu
http://www.compkarori.com/vanilla/
[27/27] from: lmecir:mbox:vol:cz at: 19-Dec-2003 7:06
Hi Joel,
I think, that:
1) Konstantin tries to use an Associative Array. I doubt, that the
suggested implementation is the best one.
>INSERTs into a "fresh" hash (created each time with MAKE HASH! []):
>Appears to be increasing faster than quadratically!
<<quoted lines omitted: 3>>
> 30000 63.682 20.777 9 2.309
> 40000 123.417 40.267 16 2.517
2) this seems to be different from my measurements (slower). Can you
post the code?
-L
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted