Don't ask to ask, just ask | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
might it be a good idea to start from scratch with a new engine, with in the beginning far less features, but FAST? No. The Everything Engine had been under development for around two years by the time Perl Monks came about. That was over three years ago. In my opinion, throwing away five years of development, when you have a working product, is a terrible idea. no more eval() It was a deliberate design decision that administrators should be able to create nodemethods that exist only in the database. It would be nice to have the option to specify that you're not using that feature for a big performance gain (and I'm working on that), but forbidding it altogether would be removing one of the most important features of Everything. implement some smart caching between application and database This is a much better idea. It's also a hard problem, with Apache and mod_perl. Threaded Apache 2.0 may help immensely. I'm also experimenting with a standalone forking server that has much more control over shared memory. Improving the existing node cache may save a bunch of time. I doubt you have profiling data, though, so I feel at liberty to say rewriting the engine from scratch is a terrible, awful, lousy idea. Just this weekend I checked in code that improved the second-biggest timesink subroutine by 50% -- without removing a single feature. Update: I forgot to bring up the idea of data migration. Good luck. In reply to Re: redesign everything engine?
by chromatic
|
|