[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]
