Re: Fusion-ifying proto parse trees

Joel de Guzman wrote:
> Oh man, we're running around in circles.
>
> 1) I mentioned the need for flat sequences on associative operators
> 2) I realized that proto-ET can be a view or generate a view that
>    gives this flat impression. You wrote some code.
> 3) We realized that there's a performance penalty compile-time/runtime
>    however you implement it (subject to testing of course)
> 4) I noted that this elaborate dance wouldn't be needed
>    where if proto had generated the flat sequences where appropriate
>    in the first place.
> 5) Now you go back to 1 and ask me why I need flat sequences.


Not to worry, we're not stuck in a groove. :-) I asked you why you 
needed flat sequences because, when I get hung up on a design problem, I 
often find it useful to go back to the beginning, start from first 
principles, and make sure that I haven't overlooked something. That's 
all. I'm not trying to tell you what you do or don't need, I'm just 
trying to understand the problem.

OK, you're saying the problem is the performance of creating a view. You 
agree, though, that there's no sense redesigning proto until we do the 
performance testing that shows there is a problem that is best addressed 
that way. Otherwise, it's just premature optimization.

I'm going to spend some time thinking about segmented Fusion algorithms, 
because I think that's where we'll get the most bang for our buck.

--
Eric Niebler
Boost Consulting
www.boost-consulting.com


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642