There is also such thing as premature "pessimization". I'm not in the position to judge whether it is appropriate in this case, though.
Oh, absolutely. In this case the issues are personal taste (Leo doesn't like the big list) and issues with specific inefficiencies in the way we've got some of the automated infrastructure being built. While there are pessimal things that need fixing it's important to look at the things that are broken, not the things that we don't like.
It would've been clearer had I taken things in front-to-back order, but I didn't -- there's a longish message that came after this one explaining what needs to be done.
On Mon, 29 Nov 2004 20:25:48 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:> Put these back.At 8:29 AM +0100 11/28/04, Leopold Toetsch wrote: >Thomas Seiler <[EMAIL PROTECTED]> wrote: >> Dan Sugalski wrote: >>> At 10:34 AM +0100 11/27/04, Leopold Toetsch wrote: >>> >>>> See also subject "Too many opcodes". >>>> >> >> [...] >> >> >>> Could you undo this please? Now is not the time to be trimming ops out. > >When is the time? After another 1000 opcodes are in, which all ought to >be functions?
Yes. Y'know, when we start doing the optimization based on a fully designed and implemented engine. Anything before that's premature. (Shall I go dig up a half dozen or more archive references with you chiding me for premature optimizations?)
> > OTOH, it won't hurt anyone and it is already in. > >That's my point.
Then your point's wrong. This patch broke a lot of my code.
You keep wanting to chop things out of the core. Stop. That's not your call -- it's mine, and it will be made, but not now.
-- Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
