John Austin wrote: > On Wed, 2003-11-19 at 15:34, Victor Mote wrote: > > ANNOUNCEMENT: I have just committed a change that 1) allows > LayoutStrategy > > to tell whether an FO Tree should be built, 2) has Driver act > on this, i.e. > > to build an FO Tree only if LayoutStrategy indicates that this should be > > done. This should theoretically allow Peter's logic to be used as a > > LayoutStrategy within the trunk development line. What I have done is > > probably overly simplistic, but I will allow Peter or anyone > wishing to work > > on that strategy tell us what additional things are needed to > accommodate. > > To start integrating, create a subclass of LayoutStrategy, override the > > foTreeNeeded() method to return false, then write a format() method that > > does the layout work. LayoutStrategy knows its parent Document, > which knows > > its parent Driver, so you should be able to get to all of the parsing > > variables that are needed. Let me know if you need help. > > > > Since configuration is still messed up, you will need to > hard-code a change > > to Driver to get your new LayoutStrategy object created. > > > > Victor Mote > > Geez! I was thinking more along the lines of plugging in a few new data > structures for property lookup. I am exploring the old implementation > through the marvel of code grooming in order to understand it.
This is not directly related to what you are doing. I realized in one of my responses to Peter yesterday that it would be easier for me to go ahead and implement the FO-Tree-less LayoutStrategy than it was to explain its theoretical possibility (again). This is an attempt to make it easier for Peter to integrate his work. If it helps you, good. If not, at least I don't think it will hurt. > Don't worry, I have the time to do this right. > > I got a tiny improvement by playing around in some of PropertyList and > PropertyListBuilder. This is just a throw-away effort of course. I did > enough tracing this a.m. to realize that my 'linear behaviour' may > be deeply buried. I have done this often enough that I don't > expect more than marginal improvements from grooming/tweaking > lines of code. [Gone are the days of PL/I and unaligned bit > fields.] > > Before I found out about Alt-Design, I was thinking about using a > HashMap with property names as keys and a class implementing > some stack behaviour. Each new FO would conceptually 'push' > new values on a stack for each property in it's list. A smart > 'pop' would allow the entire set of properties for a FO to > be popped together. Hopefully, this design would allow faster > access to the current properties, without a need to search through > higher 'activation records', 'stack frames', contexts or whatever > you choose to call them. > > The observations of performance indicate that there are millions of > accesses through PropertyList.get(String propertyName) which are > sent one-to-one through PropertyList.get( propertyName, true, true) > and thence on to PropertyList.findProperty( propertyName, true ). > > Combine this information with the fact that I didn't notice the > performance of the corresponding put() operations on the HashMap > underneath PropertyList to conclude that retrieval is much more > intensive than storage in this structure. > > So I should optimize retrievals. That certainly sounds right to me. > My plan is to get to know the internals of FOP that are 'in contact > with' the existing code, then get to know the Alt-Design, then play with > more and more of it until I feel comfortable integrating it. > > I don't expect fast-track to committer status, I would hope to work > with one or two current participants and package the changes so that > they 'drop in' to place. (We'll see) We're glad to have you involved here. Victor Mote
