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

[REBOL] Re: Profiling Rebol API to DyBASE

From: knizhnik:garret:ru at: 20-Dec-2003 21:16

Hello Gregg, Saturday, December 20, 2003, 8:02:18 PM, you wrote: GI> Hi Konstantin, GI> Thanks for your continued efforts! Thanks to your code, and Romano's GI> detective work, it seems a bug in CLEAR with hash! values may have GI> been found, which is great! GI> Also, some of us have talked about things a bit, and an expert opinion GI> is that REBOL's prototype object approach just isn't a great fit for GI> DyBase, so things may never be as good as we would like in that GI> regard. Having it work, though, and be much faster now, will still be GI> very useful. KK>> There is also yet another problem with Rebol - objects seems to be stored KK>> very inefficiently. GI> It's also creating them that has a lot of overhead. Someone noted GI> during a discussion that if you're creating 100,000 objects with 10 GI> functions each, that you're creating, and binding, 1,000,000 GI> functions. This is really awful. I also have noticed that when application creates about 100000 objects, the size of process exceeds 200Mb, and number of p[age faults is increased very fast. I thought, that once objet is created using prototype object, the values of prototype object fields are just copied to the new objects (doesn't matter whether them are scalars, series or functions). In this case there will be only one instance of the function compiled and bounded only once. But looks like it is not the case. So serious OO programming in Rebol is not possible and I have to look for alternative solution for adding persistency to Rebol. Unfortunately, DyBASE is object oriented database - i.e. it is oriented on work with objects. Object is assumed as set of fields with data and set of methods. Data is stored in DyBASE, methods - not (to make it possible to easily fix error in the program). Each object field has name and value. Objects with the same set of fields and methods belongs to one class. To minimize overhead, DyBASE create one class descriptor and all object instances, belonging to the class, contains reference to this class descriptor. Class descriptor contains class name and list of field names. Arrays and hashes are considered in DyBASE as values - so them are stored inside object and if N objects refer the same array or hash, N instances will be stored (and loaded next time when objects are accessed). Rebol objects fits in this model (the only problem is that there are no classes, so I will have to make programmer to specify prototype object for the class). But if we provide persistency not for objects, but for blocks, then it is not clear to me how to store them. There will be no field names (but will be "hidden" fields, like current position name in variables referencing series). So it is possible to write normal serialization mechanism for Rebol (one that will preserve relations between objects), and even create database, which allows not only load/store, but also change/retrieve the data. But it could not be done within DyBASE object model. First task is significantly simpler, and if such module will be really interesting to many Rebol users, I can try to develop one. GI> Two ideas that have been mentioned are GI> 1) use block! values instead of objects to interface with DyBase GI> 2) Break the functions out of the objects into a supporting GI> context, or as free functions, so you don't have to create and GI> bind them with every object. GI> Either one may require work, but could be worth investigating if GI> someone really needs the potential improvement. GI> I'm looking forward to trying the latest release. GI> Thanks again! GI> -- Gregg -- Best regards, Konstantin mailto:[knizhnik--garret--ru]