Re: Backend changes ready for commit - please test it!


Subject: Re: Backend changes ready for commit - please test it!
From: Martin Sevior (msevior@mccubbin.ph.unimelb.edu.au)
Date: Wed Feb 21 2001 - 04:58:31 CST


On Tue, 20 Feb 2001, Jesper Skov wrote:

> >>>>> "Martin" == Martin Sevior <msevior@mccubbin.ph.unimelb.edu.au> writes:
> Martin> I'm thinking about introducing a new member variable into
> Martin> fl_BlockLayout. m_bisHdrftrSection true for blocks attached
> Martin> to hdrftr sections.
>
> Martin> then fp_Run 's and fp_Line 's attached to this block could
> Martin> grab the member variable in their constructors and use it to
> Martin> short circuit any draw or clearscreen methods. That way we
> Martin> could format these HdrFtrSection blocks as usual and all the
> Martin> usual editting stuff would work fine. The draw and clearscreen
> Martin> methods would just get short circuited.
>
> Martin> ie
>
> Martin> fp_line::draw(void) { if(m_bisHdrFtrSection) return;
>
>
> Martin> What do you think?
>
> I like the idea, but not the implementation. It introduces a (arguably
> negligible) overhead on the rendering of the majority of the lines to
> work around a problem with headers/footers.
>
> Instead, make a new subclass that overrides draw with a NOP function.
>

Well let me practise my estimation skills to guess the overhead on
a return conditional on a boolean member variable.
I think

if(m_bisHdrFtrSection)
{
    return;
}

it would get compiled into at most 10 instructions which on a pentium
class computer would get executed in 10*1e^-6/200 = 0.05 microseconds.

How long does it take to draw a single character? Well let's
optimistically guess that we can refresh the entire screen in about 0.1
seconds. A screen of about 80*64 character gets redrawn in about 0.1
seconds so that means approximately 5000 characters in 0.1 seconds. So our
drawing rate is at approximately 50,000 characters per second which is 1
character per 20 microsceonds. My guess is that the overhead is then

0.05/20 = 0.0025 or 0.25%

Note that this overhead is assumed to apply to every character, which it
isn't since characters get coalesed into runs. Also the redraw in 0.1
seconds is I think a bit optimistic so really this is not going to ever be
a killer.

Regarding the subclass idea, do we reimplement every method that has
fp_run or fp_line constructor in it in our fl_HdrFtrBlockLayout subclass?
That seems likely to lead to bugs later since we have to maintain two
methods that do the same thing but call difference fp_Run and fp_line
constructors.

Am I missing something about C++ classes? Is there a away we can have
exactly the same code but just have different fp_Run and fp_Line
subclasses..

Cheers

Martin



This archive was generated by hypermail 2b25 : Wed Feb 21 2001 - 04:58:48 CST