Posted by brainless on July 7, 2006 at 6:00am
The Drupal core functions are to be implemented : that is basically all the functions defined in /includes/ directory. I am starting off with bootstrap.inc.... lets see
The Drupal core functions are to be implemented : that is basically all the functions defined in /includes/ directory. I am starting off with bootstrap.inc.... lets see
Comments
follow up....
Brainless,
I've been looking into doing this same thing. I initially started with the idea of doing "core/bootstrap", which I take to mean includes/
However, as you'll soon see, that's a massive job and once complete, you're then left chasing cvs to keep upto date. So, I thought a better method is to identify the bottlenecks and just produce a minimised PECL tyo handle those parts.
Only the really "heavy hit" sites would need such extreme streamlining, so you have to also maintain a core patch that wraps replaced functions with if (!function_exists('somefunc')) so the core php changes are minimal.
Given Dries recent blog regarding the time spent in the db abstraction, my first target is getting rid of the preg_match_callback() function. Calling PHP userspace from the extention / internals is somewhat expensive. Normally these types of things go unnoticed. However, look at just how often Drupal is using this feature. A callback into userspace for every SQL token/placeholder used. This is one place alot of time is spent at the moment. So, that's where I'm starting out.
best regards
--AjK
based on the above comment...
Based on what I said above, here's my first report...
http://spiders-lair.com/node/23
best regards,
--AjK
Yeah that is nicer and easier to start with
I have started working with bootstrap too... but yeah you are right.... updating PHP is lot easier that C so we will fall out of pace probably. We can start with bottlenecks. but we need to first decide the topmost resource consuming items / bottlenecks etc. maybe start with the top 10 or something.
brainless,
Sumit Datta,
brainlessphp.blogspot.com
brainless,
Sumit Datta,
brainlessphp.blogspot.com
Web Developer
Drupal "performance enhancing path"
True,
A "performance enhancing path" is what i am looking at. With a well coded PECL module I do not intend to see everyone moving to PECL optimised Drupal core. Rather as Ajk said... we need a solution for the 1% or so who run sites that take heavy loads. And yes starting with putting small parts of Drupal core into a PECL module is way better than putting all of Drupal core into PECL.
As for myself: My SoC project is "officially" over. Even though I will manage all aspects of my SoC project (GData), now I will finally have a lot of time to get into this project. I think we need to identify which portions need most optimisation : make a list of top 5 and make a PECL out of them and benchmark/test/release etc.
Then we can put the next 5 important ones to the PECL... and so on phase by phase.
So what should be the first 5 segments to optimise right now ? These should be 5 functions that are being done in PHP right now... like db_query( ).
brainless,
Sumit Datta,
brainlessphp.blogspot.com
brainless,
Sumit Datta,
brainlessphp.blogspot.com
Web Developer