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

[REBOL] Associative Data Storage benchmark Re:

From: joel:neely:fedex at: 23-Sep-2000 15:56

This is a multi-part message in MIME format. --------------F3AFD1FB66DE3A994B5A800F Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii By way of followup, I coded a routine for this benchmark that uses functions only, with the data stored in a block initialized to [ _keys [] _vals [] ] That block is passed as an argument to the functions that access or modify keys and values; the functions access the two sections of the block via paths. (Source code attached, if anyone cares to critique.) The ratios for a small collection of tests are: Key Nbr of Test In-line Object Functns Functns Space Testing Harness Block Method w/ Obj w/ Path Size Cycles Loop Version Version Storage Storage ------ ------- ------- ------- ------- ------- ------- 10,000 5,000 0.00% 100.00% 177.50% 175.00% 177.50% 1,000 50,000 1.92% 100.00% 183.65% 190.38% 191.35% 10,000 50,000 0.22% 100.00% 187.96% 192.34% 192.56% 100 500,000 10.31% 100.00% 214.95% 234.54% 243.81% Another surprise! It now appears to me that function entry and exit (whether object methods or "bare" functions) are the driving factor in the timings. My current conclusion is that REBOL objects are essentially tied with plain function calls, in terms of the cost/benefit tradeoff of runtime vs. readability and economy of expression. I think (unless one is using such a large number of objects that the duplication overhead is a factor) that the benefits of namespace management and potential improvements in reusability give objects the edge. -jn- [joel--neely--fedex--com] wrote:
> Relative > Loop time Comments > ==== ======== > 1 0.66% We can "do nothing" really fast! ;-) This means > that the test harness didn't distort the comparisons. > > 2 100.00% The block version. > > 3 174.17% So the cost of key-value separation, keeping all the > methods out of the global namespace, etc. is an > overhead of about 75% -- not intolerable for most > purposes. > > 4 178.15% This result makes me suspect that accessing the > components of an object is the operation that's > driving the runtime cost. > ==== ======== > > More testing (a functional version that handles key-value separation > without using an object for data storage) is clearly in order, but I > thought I'd pass on those preliminary results. >
--------------F3AFD1FB66DE3A994B5A800F Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; name="adsf2.r" Content-Disposition: inline; filename="adsf2.r" REBOL [ Title: "Minimal Associative Data Store - Function Version 2" File: %adsf2.r Date: 20-Sep-2000 Author: "Joel Neely" Purpose: { Function-based implementation of associative data store, using object for data only, with arbitrary data types for keys and values. } ] adsf2.block: func [] [ copy/deep [ _keys [] _vals [] ] ] adsf2.clear: func [ads [block!]] [ ads/_keys: copy [] ads/_vals: copy [] ads ] adsf2.empty?: func [ads [block!]] [system/words/empty? ads/_keys] adsf2.length?: func [ads [block!]] [system/words/length? ads/_keys] func [] [adsf2.block] adsf2.put: func [ads [block!] k [any-type!] v [any-type!] /local p] [ either found? p: find/only ads/_keys k [ change/only at ads/_vals index? p v ][ append/only ads/_keys k append/only ads/_vals v ] v ] adsf2.get: func [ads [block!] k [any-type!] /local p] [ either none? p: find/only ads/_keys k [ none ][ pick ads/_vals index? p ] ] adsf2.delete: func [ads [block!] k [any-type!] /local p v] [ either none? p: find/only ads/_keys k [ none ][ k: pick ads/_vals p: index? p remove at ads/_keys p remove at ads/_vals p k ] ] adsf2.keys: func [ads [block!]] [copy ads/_keys] --------------F3AFD1FB66DE3A994B5A800F--