Re: [Gzigzag-commits] gzigzag/Java/flob FTextLayouter.zob SimpleTextView.zob

[Tuomas Lukka <lukka@xxxxxxxxxx>]

On Sat, 25 Nov 2000, Benjamin Fallenstein wrote:

> Tuomas Lukka wrote:
> > On Sat, 25 Nov 2000, Benjamin Fallenstein wrote:
> > > Tuomas Lukka wrote:
> > > > But you're right: we shouldn't be solving performance problems until we
> > > > encounter them. Currently, the most important one would be VanishingView,
> > > > when depth is set to be large. That's quite slow and I suspect a part of
> > > > it is because of the FlobSet's liberal use of Vectors. But that would need
> > > > actual profiling before doing anything to make sure that that is really
> > > > the place where the trouble is. Because drawing also is significant there.
> > >
> > > Well, my FlobSet-as-Flob draft gets rid of that vector use, using
> > > pointered lists instead. Unfortunately, I'm not having enough time to
> > > make it work right now. Sometime in the next few weeks...
> > 
> > Pointered lists of flobs or of new objects? Adding a field to every flob
> > would not be nice as most cells have only one visible flob at a time, so
> > that should be the efficient case.
> 
> Pointered lists of flobs. As this doesn't need any surplus objects if
> there is only one visible flob, just a field in each flob which holds
> null, and especially as this case can be treated after a simple
> comparison of this field against null, it is the efficient case.

However, this means a penalty of 4 bytes for EACH flob, whether there is a
single flob for the cell or not. It's much better than now, but still I'd
like to do better.

But maybe that's not reasonable. It *is* possible, though, if the penalty
for the cells that have several flobs is increased.

It would be nice to get a qualitative idea of how much time we are
spending on what currently.

	Tuomas