[Firebird-devel] Rsb Type Hierarchy

[Jim S. <ja...@ne...>]

I'm almost finished with the encapsulation and refactoring of the record 
source mechanism into a type hierarchy.  The base class is very simple:

    class RecordSource
    {
    public:
        RecordSource (CompilerScratch *compilerScratch, RSB_T type);
        ~RecordSource();
        virtual void open(Request* request);
        virtual bool get(Request* request, RSE_GET_MODE mode);
        virtual void close(Request* request);
    };

The actually type hierarchy looks like this:

    RecordSource
            RsbAggregate
            RsbBoolean
            RsbCross
            RsbFirst
            RsbSequential
                   RsbIndexed
                         RsbNavigate
                         RsbExtIndexed
                         RsbExtDbkey
            RsbLeftCross
            RsbMerge
            RsbProcedure
            RsbSkip
            RsbUnion
            RsbWriteLock

Those familiar with the neighborhood will probably notice that 
RdbWriteLock is new.  The code to implement write locking used to be a 
flag test at the top of the "get" code that was executed for each rsb 
whether write locking was requested or not and whether it was 
appropriate to the rsb type or not.  (The write lock code also make 
structural assumptions about what patterns of rsb could be generated, 
which is a different issue entirely).  I yanked the general flag test in 
favor of a special rsb that is generated only if record locking has 
actually been requested.

This is a good example of how software gets slow.  The right way to 
implement something like that is to use the structure in place, in this 
case the rsb mechanism, so the code only have to executed if it's 
needed.  The wrong way is to hack it into the most general place with a 
special purpose flag.  Nothing robs a system of performance like 
checking flags thousands or hundred thousands of times in the same 
request when it's going to be false every time.  Firebird is absolutely 
rife with the problem.

My guess is that the average code path to fetch an indexed record is 
around a quarter to a third of what it was before, and there's a lot 
more house cleaning to do.

Next on my list to get rid of the silly flags that tell the rsb 
mechanism whether or not the record could should be incremented, 
probably with an RsbCount class generated at the strategic point.

Now that the RsbMechanism has been tamed, it would be a good time to 
think about adding pseudo tables to reflect active attachments and 
running requests.  Each could be implemented with an independent Rsb 
subclass.  Any takers?

-- 

Jim Starkey
Netfrastructure, Inc.
978 526-1376