Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

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