[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: [zzdev] Cachable deductible structures
- To: Benjamin Fallenstein <b.fallenstein@xxxxxx>
- Subject: Re: [zzdev] Cachable deductible structures
- From: Tuomas Lukka <lukka@xxxxxxxxxx>
- Date: Thu, 14 Dec 2000 02:52:30 +0200
- Cc: ZZ Development <zzdev@xxxxxxxxxx>, Tuomas Lukka <lukka@xxxxxxxxxxx>
- In-reply-to: <3A37ECAA.2E38CCAA@xxxxxx>; from b.fallenstein@xxxxxx on Wed, Dec 13, 2000 at 10:39:55PM +0100
- Mail-followup-to: Benjamin Fallenstein <b.fallenstein@xxxxxx>, ZZ Development <zzdev@xxxxxxxxxx>, Tuomas Lukka <lukka@xxxxxxxxxxx>
- References: <3A37ECAA.2E38CCAA@xxxxxx>
> do you think it makes sense to implement objects which are deducted from
> the structure (e.g., nile paragraph ftexts or ZOb) as observers (ZZObs)
> and have them refresh themselves when the structure changes? Then we
> could cache them -- much more of a memory save than having style objects
> for ftext parts, I should think.
> For ZOb stuff, that should be quite straightforward -- we'd just need to
> change the parser. OTOH, we need to write a caching system that knows
> when to dispose of these things -- not that easy. And ZOb stuff really
> aren't a bottleneck -- nile paragraphs would be better, I'd think.
> However, there implementation is probably not as easy...
Have I got a nice surprise for you ;)
Have you looked at ZZObs and ZZObsTrigger?
Then, note that most ZZCell routines have a form that takes an optional
It *MAY* not work perfectly with ZZCacheDimSpace currently but if it doesn't,
it's a bug.
So basically, to do the paragraph, you'd just need to keep giving the right
ZZObs to the ZZCells all the time and have that ZZObs blow that paragraph's
However, I'd *really* like to see some profiling results before beginning
to implement and test all this - because it *will* make it easier to
have bugs. The current system is fairly stable and bugs are easy to find
and fix once we know about them because we have almost no state at all aside
from the ZZ structure. Caching would introduce a LOT more state. It's
still not as bad as conventional programs: there should always be
an exact correspondence between a well-defined part of the structure
and a cached object but it does get more complicated to make absolutely
sure that no changes to the structure can occur without the right refresh
occurring as well.
So I wouldn't want to go down this route before we *know* there is a real,
quantifiable and sizable benefit.