Coding Standards and Performance Optimization

Benchmarking in Drupal

Shyamala@drupal.org — Fri, 01 Aug 2008 12:20:03 +0000

Drupal and MySQl located in two different servers:

Configuration: Drupal server: Dual core processor, 4GB RAM
MySQL Server: Xeon Processor, 4GB RAM

MySQL Enterprise edition 5

In an exercise to Pre populate the database with 1 million records, record insertions in the tables are very slow since the requests are getting queued up in the database. Insertion is done using a special tool that records our drupal application and plays back the scripts in a loop to populate the database.

Please see the below data collected by the team.

5minutes-25users-1051 records updated
5minutes-50users-1029 records updated
5minutes-100users- 1012 records updated

As users increases, the no of records creation decreases, also after the test has been stopped, it has been noticed that it is updating the database. Moreover if we are planning to run the test for long hours, I am afraid that the queue will increase and make the database to reach unsteady state.

What could be the cause for such an issue, what MySQl tuning is recommended?

MySQL

"elseif" vs "else if"

stella — Fri, 18 Jul 2008 20:31:04 +0000

In the latest code review done by chx and Morbus at http://www.drupaltoughlove.com, one of the items commented on was the usage of "else if" instead of "elseif". There's nothing in the Coding Standards doc that specifically states that one should be used over the other, however it is "implied" from the first example on indentation that "elseif" should be used. Can the Coding Standards doc be updated so that it states one way or the other? Personally I don't mind which, but I would prefer if there was consistency. Core itself has a mixture, but with a higher number of "elseif".

An issue on this has already been raised at http://drupal.org/node/282405

Cheers,
Stella

Coding Standards and Performance Optimization

Doxygen @file directives

stella — Fri, 18 Jul 2008 12:33:11 +0000

In the Doxygen formatting conventions doc, it says that files should be documented with the @file directive and gives the following example:

<?php
// $Id: theme.inc,v 1.202 2004/07/08 16:08:21 dries Exp $

/** * @file * The theme system, which controls the output of Drupal. * * The theme system allows for nearly all output of the Drupal system to be * customized by user themes. */

Note the @file line in particular.

Further down the same doc, under the section on "Documenting theme templates", the @file directive example is different:

<?php
// $Id$

/** * @file forum_list.tpl.php * Default theme implementation to display a list of forums. * * Available variables: * - $forums: An array of forums to display. * * Each $forum in $forums contains: * - $forum->is_container: Is TRUE if ........... * * @see template_preprocess_forum_list() */

In the first example, the @file directive was just @file whereas in the second it is followed by the filename, @file forum_list.tpl.php. I would like this to be more consistent. I would prefer if we just decided on one convention which would be used on all files, regardless of file type.

Personally, I'm in favour of removing the need for the filename, and have some reasons:

First of all, the filename is already specified in the $Id$ line. In the example above, it's just $Id$, but this is filled out to include the filename and version information when the file is committed to CVS. I don't see any benefit to having the filename specified again in the @file section.
Have this filename here kinda messes up the API documentation. See http://api.drupal.org/api/files and look at any of the .tpl.php file entries, the filename is stated again in the file description and also appears in the file description on the file's documentation page. It doesn't cause problems per se, it just doesn't look clean.
My last point is fairly minor. The Coder module already has checks in place for the @file directive, but expects nothing to follow it on the same line. Changes will be required to this module if we are to keep the filename specification.

Cheers,
Stella

+1 from me; stella, merlinofchaos, and I had discussions of it. --Morbus Iff.
+1 from me, too. --sun (PS: A discussion would probably have been more appropriately ;)
+1 - since that's 3-4 of us, I updated the page to remove that one filename from the example too --catch

Excellent, now I just need to provide patches to update the template files in core. Thanks - Stella

Coding Standards and Performance Optimization

Javascript Coding Standards

stella — Fri, 18 Jul 2008 12:02:04 +0000

More and more contrib modules are including JavaScript files, so I want to add the ability to review JavaScript files to the Coder module. However, step 1 is we need to agree on what coding standards we should be using for JavaScript.

At present we have the Coding standards for JS files doc which has one or two ideas but isn't complete. We also have the main Coding Standards doc, and while most are transferable to JavaScript, not all are. So I've put some suggestions together at http://drupal.org/node/260140 A fair few of them come from the standards used by JSLint so there shouldn't be many surprises. I'd really appreciate a discussion on this and hopefully we can agree on the coding standards we want to use.

Coding Standards and Performance Optimization

Performance Profiling System

echoditto_tom — Sat, 22 Mar 2008 03:55:14 +0000

Moved to official ideas list

We'd like to propose the development of a profiling module and possible API capable of collecting performance data for hook invocations and calls to enabled functions in addition to the theme and database timings reported by the Devel and Devel Themer modules. The output of this module could include full traces of hooks, theme functions, database queries, external API requests and other functions similar to the trace files generated by debugging tools like XDebug but tailored to provide information that is useful to module developers and site builders. Other useful reports might include ranked execution times to highlight problem code and statistical aggregates gathered multiple page loads.

Development of this module will involve an understanding of Drupal's inner workings and will provide an excellent opportunities to learn the details of how each page is built from the ground up. It will also provide a great service to the Drupal development community, Drupal integrators and systems administrators. Use of the devel module is fine for identifying runaway queries, but it can be difficult to tie this to a complete picture of the system's modules, particularly if a module is making too many API calls rather than just too many large database queries, is making use of suboptimal algorithms or is encountering systems-level bottlenecks.

In the past we've had to spend time examining Drupal modules on client sites to determine which are most responsible for page load times, database and overall system load. This involved process is lengthy and usually not pretty, involving numerous one-off hacks to core to enable needed reporting followed by hammering the site with a/b tests and tools not optimal for debugging the Drupal stack. This project would not only provide a vastly improved interface for the debugging and optimization of Drupal code and live installations, but would also provide the groundwork for an approach to full-stack PHP debugging which takes the needs and conditions of Drupal development as its initial focus.

A list of potential features includes:

selective activation -- process only fires for specified user roles, IP pools or for a percentage of page loads so as to not affect overall performance
complete trace dumps of Drupal page generation stack
"problem functions" report for system administrators and others evaluating code in the wild
collection of stats re: authenticated:unauthenticated session ratio
optional integration with Drupal's throttle mechanism based on the results of the profiling
display of stats through pretty graphs (Google Chart API or similar)

EchoDitto would be glad to provide mentorship to any students who end up undertaking this task.

Coding Standards and Performance Optimization

Develop an xss and sql injection scanner based on SimpleTest

ingo86 — Fri, 14 Mar 2008 15:02:03 +0000

What I wanna develop for SOC 2008 is a module called security (or add security function to simpletest existing module) to enable users checking their drupal installation against xss and sql injection vulnerabilities.
It will be also good for module developers, in fact they can check their module before submitting them to drupal website. Users could be more protected against vulnerabilities that became from third part modules.
The objective of this work is to realize automated penetration test on drupal installation.

It will be based upon SimpleTest, already used by Rasmus (php core developer) to develop his own closed source xss scanner. SimpleTest is a jUnit similar library written for php.

My module could easily been extended to add more functionalities about security, but basically I think that this two are the most important.
If someone has functionality ideas to improve my project and make it better I'm here, listening for more proposal.

Coding Standards and Performance Optimization

Improving Drupal's page loading performance

Wim Leers@drupal.org — Wed, 30 Jan 2008 22:51:03 +0000

This article I wrote should appeal to people interested in high performance Drupal sites. Most of the performance gains are achieved by doing things with the Javascript and Drupal's File API.

http://wimleers.com/article/improving-drupals-page-loading-performance

You can expect another article soon, about the same topic, but then putting it to practice. I'll use the CDN integration module (of which I'm also the maintainer) and the included core patches to do it in just a few simple steps.

High performance

GHOP #127: Benchmark results table

Corni — Fri, 18 Jan 2008 16:57:05 +0000

Hi,
I need a table for #127, so it will go here :)
This table is now fully complete :)

Test Page	Caching	Drupal 5 requests/sec	Drupal 5 overalltime	Drupal 6 requests/sec	Drupal 6 overalltime	% differences for Drupal 6(based on requests/s)
Index with 30 nodes	No	3.64	55.13	3.42	58.46	-06%
	normal	136.62	1.46	109.09	1.83	-20%
	aggresive	161.51	1.23	114.48	1.74	-29%
Taxonomy Term (taxonomy/term/111&page=2)	No	5.16	38.73	4.71	42.44	-08%
	normal	not reliable accooding to ab	^^^	111.59	1.79	?
	aggresive	167.31	1.19	118.29	1.68	-29%
1 node with _lots_ of comments	No	3.56	56.25	3.38	59.20	-05%
	normal	149.64	1.33	116.35	1.71	-22%
	aggresive	177.58	1.12	results not reliable according to ab	^^^^	?
Forum Index	No	11.78	16.97	10.82	18.49	-08%
	normal	158.98	1.25	122.03	1.63	-23%
	aggresive	163.62	0.61	130.43	1.53	-20%
Search result	No	1.07	187.37	1.12	178.22	+04%
	normal	150.46	1.32	115.46	1.73	-23%
	aggresive	177.76	1.12	125.70	1.59	-29%

This is the old table, it is not relevant and only here for comparison!!!

Test Page	Caching	Drupal 5 requests/sec	Drupal 5 overalltime	Drupal 6 requests/sec	Drupal 6 overalltime	% differences for Drupal 6(based on requests/s)
Index with 30 nodes	No	3.74	26.71	3.40	29.39	-09%
	normal	101.68	0.98	81.53	1.22	-19%
	aggresive	114.13	0.87	84.79	1.17	-25%
Taxonomy Term (taxonomy/term/111&page=2)	No	5.34	18.72	4.72	21.19	-11%
	normal	109.44	0.91	84.82	1.17	-22%
	aggresive	101.50	0.98	88.99	1.12	-12%
1 node with _lots_ of comments	No	3.60	27.80	3.37	29.69	-06%
	normal	105.26	0.94	83.53	1.19	-20%
	aggresive	118.43	0.84	87.12	1.14	-26%
Forum Index	No	11.91	8.39	10.92	9.16	-08%
	normal	140.51	0.71	109.99	0.90	-21%
	aggresive	163.62	0.61	116.18	0.86	-28%
Search result	No	1.09	91.77	1.15	87.64	+05%
	normal	63.50	1.57	56.58	1.76	-10%
	aggresive	67.90	1.47	58.10	1.72	-14%

Link to GHOP Issue #127: http://drupal.org/node/206570

Google Highly Open Participation Contest (GHOP)

Coder format! or: Make everything Drupal.

sun — Fri, 18 Jan 2008 12:43:00 +0000

In case you don't know, Edward Z. Yang (ezyang) is squashing a lot of bugs in coder_format in the scope of a GHOP task currently.
In case you don't know coder_format, it's a script I wrote some time ago which re-formats one PHP file, or recursively all files in a directory according to Drupal's Coding Standards. Doug Green has been so kind to add it to the Coder module, so if you are a Drupal developer, you probably have (an out-dated version of) it already. Unfortunately, it did not receive that much attention yet.

I do not yet want to promote coder_format with this post. Today, I just want to show you the results of an experiment, which in turn will show you, what you can expect from coder_format.

Guess, what this ugly code snippet is:

<?php
function drupal_add_feed($url = NULL, $title = '') { static $stored_feed_links = array(); if (!is_null($url) && !isset($stored_feed_links[$url])) { $stored_feed_links[$url] = theme('feed_icon', $url, $title); drupal_add_link(array('rel' => 'alternate', 'type' => 'application/rss+xml', 'title' => $title, 'href' => $url)); } return $stored_feed_links; } function drupal_get_feeds($delimiter = "\n") { $feeds = drupal_add_feed(); return implode($feeds, $delimiter); } function drupal_query_string_encode($query, $exclude = array(), $parent = '') { $params = array(); foreach ($query as $key => $value) { $key = drupal_urlencode($key); if ($parent) { $key = $parent .'['. $key .']'; } if (in_array($key, $exclude)) { continue; } if (is_array($value)) { $params[] = drupal_query_string_encode($value, $exclude, $key); } else { $params[] = $key .'='. drupal_urlencode($value); } } return implode('&', $params); } function drupal_get_destination() { if (isset($_REQUEST['destination'])) { return 'destination='. urlencode($_REQUEST['destination']); } else { $path = isset($_GET['q']) ? $_GET['q'] : ''; $query = drupal_query_string_encode($_GET, array('q')); if ($query != '') { $path .= '?'. $query; } return 'destination='. urlencode($path); } } function drupal_goto($path = '', $query = NULL, $fragment = NULL, $http_response_code = 302) { if (isset($_REQUEST['destination'])) { extract(parse_url(urldecode($_REQUEST['destination']))); } else if (isset($_REQUEST['edit']['destination'])) { extract(parse_url(urldecode($_REQUEST['edit']['destination']))); } $url = url($path, array('query' => $query, 'fragment' => $fragment, 'absolute' => TRUE)); $url = str_replace(array("\n", "\r"), '', $url); if (!defined('MAINTENANCE_MODE') || MAINTENANCE_MODE != 'update') { module_invoke_all('exit', $url); } session_write_close(); header('Location: '. $url, TRUE, $http_response_code); exit(); } function drupal_site_offline() { drupal_maintenance_theme(); drupal_set_header('HTTP/1.1 503 Service unavailable'); drupal_set_title(t('Site off-line')); print theme('maintenance_page', filter_xss_admin(variable_get('site_offline_message', t('@site is currently under maintenance. We should be back shortly. Thank you for your patience.', array('@site' => variable_get('site_name', 'Drupal')))))); } function drupal_not_found() { drupal_set_header('HTTP/1.1 404 Not Found'); watchdog('page not found', check_plain($_GET['q']), NULL, WATCHDOG_WARNING); if (!isset($_REQUEST['destination'])) { $_REQUEST['destination'] = $_GET['q']; } $path = drupal_get_normal_path(variable_get('site_404', '')); if ($path && $path != $_GET['q']) { menu_set_active_item($path); $return = menu_execute_active_handler($path); } if (empty($return) || $return == MENU_NOT_FOUND || $return == MENU_ACCESS_DENIED) { drupal_set_title(t('Page not found')); $return = t('The requested page could not be found.'); } print theme('page', $return, FALSE); }
?>

No, it is not some nasty code that I found somewhere on the net. It's a stripped version of common.inc from Drupal 6 generated with

php -w includes/common.inc > common.stripped.inc

And, it is an example for some PHP code that does not follow Drupal's Coding Standards at all.

Guess again, how this snippet will look after processing it with coder_format. Ready? Go!

<?php
function drupal_add_feed($url = NULL, $title = '') {
  static $stored_feed_links = array();
  if (!is_null($url) && !isset($stored_feed_links[$url])) {
    $stored_feed_links[$url] = theme('feed_icon', $url, $title);
    drupal_add_link(array('rel' => 'alternate', 'type' => 'application/rss+xml', 'title' => $title, 'href' => $url));
  }
  return $stored_feed_links;
}
function drupal_get_feeds($delimiter = "\n") {
  $feeds = drupal_add_feed();
  return implode($feeds, $delimiter);
}
function drupal_query_string_encode($query, $exclude = array(), $parent = '') {
  $params = array();
  foreach ($query as $key => $value) {
    $key = drupal_urlencode($key);
    if ($parent) {
      $key = $parent .'['. $key .']';
    }
    if (in_array($key, $exclude)) {
      continue;
    }
    if (is_array($value)) {
      $params[] = drupal_query_string_encode($value, $exclude, $key);
    }
    else {
      $params[] = $key .'='. drupal_urlencode($value);
    }
  }
  return implode('&', $params);
}
function drupal_get_destination() {
  if (isset($_REQUEST['destination'])) {
    return 'destination='. urlencode($_REQUEST['destination']);
  }
  else {
    $path = isset($_GET['q']) ? $_GET['q'] : '';
    $query = drupal_query_string_encode($_GET, array('q'));
    if ($query != '') {
      $path .= '?'. $query;
    }
    return 'destination='. urlencode($path);
  }
}
function drupal_goto($path = '', $query = NULL, $fragment = NULL, $http_response_code = 302) {
  if (isset($_REQUEST['destination'])) {
    extract(parse_url(urldecode($_REQUEST['destination'])));
  }
  else if (isset($_REQUEST['edit']['destination'])) {
    extract(parse_url(urldecode($_REQUEST['edit']['destination'])));
  }
  $url = url($path, array('query' => $query, 'fragment' => $fragment, 'absolute' => TRUE));
  $url = str_replace(array("\n", "\r"), '', $url);
  if (!defined('MAINTENANCE_MODE') || MAINTENANCE_MODE != 'update') {
    module_invoke_all('exit', $url);
  }
  session_write_close();
  header('Location: '. $url, TRUE, $http_response_code);
  exit();
}
function drupal_site_offline() {
  drupal_maintenance_theme();
  drupal_set_header('HTTP/1.1 503 Service unavailable');
  drupal_set_title(t('Site off-line'));
  print theme('maintenance_page', filter_xss_admin(variable_get('site_offline_message', t('@site is currently under maintenance. We should be back shortly. Thank you for your patience.', array('@site' => variable_get('site_name', 'Drupal'))))));
}
function drupal_not_found() {
  drupal_set_header('HTTP/1.1 404 Not Found');
  watchdog('page not found', check_plain($_GET['q']), NULL, WATCHDOG_WARNING);
  if (!isset($_REQUEST['destination'])) {
    $_REQUEST['destination'] = $_GET['q'];
  }
  $path = drupal_get_normal_path(variable_get('site_404', ''));
  if ($path && $path != $_GET['q']) {
    menu_set_active_item($path);
    $return = menu_execute_active_handler($path);
  }
  if (empty($return) || $return == MENU_NOT_FOUND || $return == MENU_ACCESS_DENIED) {
    drupal_set_title(t('Page not found'));
    $return = t('The requested page could not be found.');
  }
  print theme('page', $return, FALSE);
}
?>

Please bear in mind, that php -w strips all comments and white-space from a PHP file.

Now, guess again, what a diff between the original common.inc from Drupal 6 and the code above (which has not been altered) will show you. I won't tell. You might look at the attached patch :)

If you want to support this effort, please help in finding wrong applied formattings by coder_format in the GHOP #136: Improve coder_format to re-format Drupal 6 core without wrong formattings issue, respectively in the corresponding wiki page.

Daniel F. Kudwien
unleashed mind

Drupal Dojo

GHOP #136: Improve coder_format checklist

ezyang — Wed, 16 Jan 2008 21:44:36 +0000

This page is for tracking the findings of GHOP #136 in coder_format of the coder module.

Legend: See below.

includes/

File	Function	Issue	Status
		Remove spaces from lines with only whitespace	FIXED
actions.inc		Excessive spacing for assignment alignment	BOGUS
batch.inc		`$var =& func()` converted to `$var = &func()`	OK
bootstrap.inc		// Capitalize and punctuate inline comments.	POSTPONED
bootstrap.inc	watchdog	Array spacing collapsed	POSTPONED
cache.inc			OK
cache-install.inc			OK
common.inc	drupal_urlencode	// inside /* */ should not be triggered	FIXED
common.inc	drupal_urlencode	// inside '' should not be triggered	FIXED
common.inc	drupal_common_theme	Indent of closing parenthesis of an multi-line array should always have the same indent like the array key or the variable name, e.g. `<?php $var = array( 'install_page' => array( 'arguments' => array('content' => NULL), ), ); ?>` coder_preprocessor_ml_array_add_comma() should add a comma to multi-line array values, which required for `case ')'`.	FIXED
common.inc	element_sort	Hyphen in -1 should not be separated	FIXED
database.inc			OK
database.mysql.inc			OK
database.mysql-common.inc			OK
database.mysqli.inc	db_error	Wrong usage of inline comments /* */ (should be //) is moved below contextual line.	BOGUS
database.pgsql.inc			OK
file.inc	file_save_upload	Improper usage of inline comment in front of case statement.	BOGUS
file.inc	file_download	Negative sign in parenthesis should not have whitespace	FIXED
form.inc	theme_image_button	Long concatenated string merged to one line	BOGUS
form.inc	batch_get	function &foo() should not contain space between ampersand and name	FIXED
image.gd.inc			OK
image.inc			OK
install.inc	drupal_rewrite_settings	// inside // should not be triggered	FIXED
install.mysql.inc			OK
install.mysqli.inc			OK
install.pgsql.inc			OK
language.inc			OK
locale.inc	_locale_import_read_po	Proper inline comment (containing a colon and comma) is placed below statement.	FIXED
locale.inc	_locale_get_predefined_list	Improper usage of multiline comment as inline comment.	BOGUS
mail.inc	drupal_mail_send	Closing parenthesis should have same indent like return statement.	FIXED
menu.inc	menu_tree_page_data	Placements of while and while in a do ... while statement seem to be exchanged/corrupt.	FIXED
module.inc			OK
pager.inc			OK
path.inc			OK
session.inc			OK
tablesort.inc			OK
theme.inc			OK
theme.maintenance.inc			OK
unicode.inc			OK
xmlrpc.inc			OK
xmlrpcs.inc			OK

modules/

File	Function	Issue	Status
filter.module	_filter_htmlcorrector	Wrong formatting applied for accessing a single string character using the curly brace syntax.	FIXED
node.module	node_filter_form	postprocessor multiple_vars() should not match multiple lines that are separated by a blank line.	FIXED

Legend:
"BOGUS" means that the original code is considered wrong. coder_format follows a strict coding guideline and is not able to think like a human. This means that a developer has to write code (including comments) that is logically correct and basically follows these guidelines, too. For example, you should not wonder why something like

<?php
$foo = 'Hello word,'
  . 'this is some kind of'
  . 'ugly string concatenation.';
?>

will be re-formatted to

<?php
$foo = 'Hello word,' . 'this is some kind of' . 'ugly string concatenation.';
?>

If a developer really wanted to separate these strings onto multiple lines, a proper syntax should have been used:

<?php
$foo = 'Hello word,';
$foo .= 'this is some kind of';
$foo .= 'ugly string concatenation.';
?>

Google Highly Open Participation Contest (GHOP)

Performance Profile of D6 (3 pages)

Corni — Tue, 11 Dec 2007 20:45:23 +0000

This is my GHOP task, for further information look at http://drupal.org/node/196907

The Text from there ;)
For GHOP Drupal-Issue 4 I did a profiling of D6.
The Comp Specs are:
Core2Duo E6320 (overclocked, both Cores 2,24Ghz)
4GB Mem
HDD - don't know :P should be 72000rpm, 8MB Cache or so
Gentoo Linux, Kernel 2.6.21-tuxonice-gentoo-r6 running X
1. Analysis of a fresh installed D6-HEAD (12.09.07) start page after installing (runned cron 1 time manually, please note that the standard page IS NOT saved into db)

Overall stats:
It tooks about 12ms to build the complete page (jep, now it's a much faster Computer :p)

The complete drupal_bootstrap-call took 9,3ms aka ~70%. It called 9 times _drupal_bootstrap. Analysis of the calls will follow. Most of the rest time is spent into the theme-function, 2,9ms (23%), analysis will follow. menu_executive is smart, so don't worry about it (at least here :D)
Analysis of drupal_bootstrap:

Here is the function _drupal_bootstrap_full to mention, here you can focus on, it's consuming ~50% of the execution time(6ms) to execute it's code+calls to other funcs. More then 50% of it's time goes to the modules_load_all aka drupal_load calls. Here you could try to find a timeoptimized version for, but the code is rather short, not too much you're able to optimize. The Calls itself looks smart anyway, but having each call, and imagine having a high amount of modules, it will matter.
Analysis of theme:

The theme-function including it's the other ~30% of the page generation time. It have a big Callstack, and while I clicked through it, I just saw the time goes down with each layer, but I am not able to say THERE it goes. sorry guys. Only recommendation: Think of a ~100lines template engine :p It can have loops and ifs and it should be smart (didn't do a profiling on it)
2. Submitting a new Story-Form

Creating a story consumes 15ms time
Here is nothing really new, differing from the old Computer, all is fine, except from the points talked above, we need ~50% for the bootstrap thing, ~30% for the theme, and ~25% for the menu_executive_active_handler. Tracking down some time loosed in theme(), I came across theme_render_template, it needs 1,3ms without having a call stack, so look there if you want to remove some crappy PHP logic ;)
The other's doesn't seems to be that wasting, but they have a deep call stack you could try to lower
3. Adminindex

I'll just post the additional infos, the rest is like 1.
it needs 61(!)ms to be built, 8,8ms goes into drupal_bootstrap, 3,6ms into theme and 48ms!!!(80% of page generation time) into menu_executive_handler. Now, you sure asks. Why are we loosing that much time for building the admin index? it's 6x slower then the other one's! We start with menu_executive_handler itself. It needs 5,8ms for itself (without calls), his is imho too long. The most other time is spemt into a bug (to my understanding) of update.status-module, 38ms of the total page generation time goes into the function system_status. You don't need to compute your huge array for all modules ecvery time the admin visits the admin index, uh? Just cache the results of the last check (on cron and after adding a new module) and display these on the admin index. It will safe you at least 33ms. Is this an argument? :P I'll file a bug because of this to update_status :)
All other Calls of admin index seems to be ok, no other problems found

For Questions contact me in #drupal or #drupal-ghop, nick Corni or drop a mail(cDOTr1ATgmxDOTde)

The Profileroutpout is attached, strip the .txt ;)

Coding Standards and Performance Optimization

candidate node, user, and system functions for module splt

pwolanin — Fri, 20 Jul 2007 17:35:23 +0000

Draft list from chx:

function node_node_operations() {
function node_operations_publish($nodes) {
function node_operations_unpublish($nodes) {
function node_operations_promote($nodes) {
function node_operations_demote($nodes) {
function node_operations_sticky($nodes) {
function node_operations_unsticky($nodes) {
function node_filters() {
function node_build_filter_query() {
function node_filter_form() {
function theme_node_filter_form($form) {
function theme_node_filters($form) {
function node_filter_form_submit($form, &$form_state) {
function node_admin_nodes_submit($form, &$form_state) {
function node_admin_nodes_validate($form, &$form_state) {
function node_admin_content() {
function node_admin_nodes() {
function theme_node_admin_nodes($form) {
function system_main_admin_page($arg = NULL) {
function system_admin_menu_block_page() {
function system_admin_theme_settings() {
function system_admin_theme_submit($form, &$form_state) {
function system_theme_select_form(&$form_state, $description = '', $default_value = '', $weight = 0) {
function theme_system_theme_select_form($form) {
function _system_zonelist() {
function system_site_information_settings() {
function system_clean_url_settings() {
function system_error_reporting_settings() {
function system_performance_settings() {
function system_file_system_settings() {
function system_image_toolkit_settings() {
function system_rss_feeds_settings() {
function system_date_time_settings() {
function system_date_time_settings_submit($form, &$form_state) {
function system_site_maintenance_settings() {
function system_themes_form() {
function theme_system_themes_form($form) {
function system_themes_form_submit($form, &$form_state) {
function system_modules($form_state = array()) {
function system_modules_disable($form, $edit) {
function system_modules_confirm_form($modules, $storage) {
function system_module_build_dependencies($modules, $form_values) {
function system_modules_submit($form, &$form_state) {
function theme_system_modules($form) {
function system_modules_uninstall($form_state = NULL) {
function system_modules_uninstall_confirm_form($storage) {
function theme_system_modules_uninstall($form) {
function system_modules_uninstall_validate($form, &$form_state) {
function system_modules_uninstall_submit($form, &$form_state) {
function system_theme_settings(&$form_state, $key = '') {

function user_admin_perm($rid = NULL) { function theme_user_admin_perm($form) { function user_admin_perm_submit($form, &$form_state) { function user_admin_role() { function user_admin_role_validate($form, &$form_state) { function user_admin_role_submit($form, &$form_state) { function theme_user_admin_new_role($form) { function user_admin_account() { function theme_user_admin_account($form) { function user_admin_account_submit($form, &$form_state) { function user_admin_account_validate($form, &$form_state) { function user_user_operations($form_state = array()) { function user_user_operations_unblock($accounts) { function user_user_operations_block($accounts) { function user_multiple_role_edit($accounts, $operation, $rid) { function user_multiple_delete_confirm(&$form_state) { function user_multiple_delete_confirm_submit($form, &$form_state) { function user_admin_settings() { function user_admin($callback_arg = '') { function user_admin_check_user() { function user_admin_check_mail() { function user_admin_check_host() { function user_admin_access_check() { function user_admin_access_check_validate($form, &$form_state) { function user_admin_access_check_submit($form, &$form_state) { function user_admin_access_add($mask = NULL, $type = NULL) { function user_admin_access_delete_confirm($aid = 0) { function user_admin_access_delete_confirm_submit($form, &$form_state) { function user_admin_access_edit($aid = 0) { function user_admin_access_form(&$form_state, $edit, $submit) { function user_admin_access() { function user_filters() { function user_build_filter_query() { function user_filter_form() { function theme_user_filter_form($form) { function theme_user_filters($form) { function user_filter_form_submit($form, &$form_state) {

Coding Standards and Performance Optimization

Break up core page handlers to include files

Crell@drupal.org — Wed, 23 May 2007 03:54:17 +0000

http://drupal.org/node/140218 now makes this possible: http://drupal.org/node/146172

So let's do it. :-)

Core still needs to be factored out to separate page include files. If you're interested in helping out, grab a module below. Please follow the guidelines listed in the documentation page above. If you feel the documentation page should be changed, comment on the book page so we can keep that all together in one place.

A starting list of functions in node, user, and system: http://groups.drupal.org/node/5239. Note, however, that some of this (especially node) may be touched by the actions patch.

actions/trigger: Volunteer: Crell / dmitrig01; Issue/Status: Done; Blocked on:
aggregator: Volunteer: Crell; Issue/Status: Done; Blocked on: N/A
block: Volunteer: Crell; Issue/Status: Done; Blocked on:
blog: Volunteer: Crell; Issue/Status: Done; Blocked on:
blogapi: Volunteer:; Issue/Status: N/A (No page callbacks); Blocked on:
book: Volunteer: Crell; Issue/Status: Done; Blocked on:
color: Volunteer:; Issue/Status: N/A (No page callbacks); Blocked on:
comment: Volunteer: Crell; Issue/Status: Done; Blocked on:
contact: Volunteer: Crell; Issue/Status: Done; Blocked on:
dblog: Volunteer: Crell; Issue/Status: Done; Blocked on:
drupal: Volunteer: Crell; Issue/Status: Done; Blocked on:
filter: Volunteer: Crell; Issue/Status: Done; Blocked on:
forum: Volunteer: Crell; Issue/Status: Done; Blocked on:
help: Volunteer: Crell; Issue/Status: Done; Blocked on:
locale: Volunteer: Crell; Issue/Status: http://drupal.org/node/187398; Blocked on:
menu: Volunteer: pwolanin; Issue/Status: Done; Blocked on:
node: Volunteer: pwolanin; Issue/Status: Done; Blocked on:
openid: Volunteer: Crell; Issue/Status: Done; Blocked on:
path: Volunteer: Crell; Issue/Status: Done; Blocked on:
ping: Volunteer:; Issue/Status: N/A (no page callbacks); Blocked on:
profile: Volunteer: Crell; Issue/Status: http://drupal.org/node/191544; Blocked on:
php: Volunteer:; Issue/Status: N/A (No page callbacks); Blocked on:
poll: Volunteer: Crell; Issue/Status: Done; Blocked on:
statistics: Volunteer: Crell; Issue/Status: Done; Blocked on:
syslog: Volunteer:; Issue/Status: N/A (too small to bother); Blocked on:
taxonomy: Volunteer: Crell; Issue/Status: Done; Blocked on:
tracker: Volunteer: Crell; Issue/Status: Done; Blocked on:
translation: Volunteer: Crell; Issue/Status: Done; Blocked on:
search: Volunteer: Crell and dvessel; Issue/Status: Done; Blocked on:
system: Volunteer: Crell / pwolanin; Issue/Status: Done; Blocked on:
throttle: Volunteer: Crell; Issue/Status: Done; Blocked on:
upload: Volunteer: bennybobw; Issue/Status: Done & Committed; Blocked on:
update: Volunteer: dww; Issue/Status: Done; Blocked on:
user: Volunteer: Crell and dvessel; Issue/Status: Done; Blocked on:

For some of the very-common page handlers like node_page, we should do some benchmarking to see if it's better to leave them in the main .module file, give them their own dedicated include file, or put them in with the rest of the handlers for that module. Whoever does that module, please look into it. :-)

Documentation must be updated accordingly.

Remember to check other modules to see if they use the handlers you are separating out!

Coding Standards and Performance Optimization

Performance review of object translation required

Gábor Hojtsy — Tue, 08 May 2007 11:25:16 +0000

We have posted a patch to support object translation of certain Drupal objects (content types, user profile fields and categories, site settings, and so on) to multiple human languages. While we have clear concepts and very good ideas for the user interface (which we though before that would not be easy), performance-wise we are at crossroads. We would welcome beginner as well as expert reviewers to come and share their performance ideas about Drupal object translation, so Drupal 6 can include a mature translation infrastructure, advancing ahead of the competition. ;) We need your input!

"Introduce dynamic object translation API (optimize this!)" http://drupal.org/node/141461

Translations

Random ID Generation Write up

Souvent22@drupal.org — Tue, 24 Apr 2007 02:58:43 +0000

So, I've had a few inquiries over the last few months about random node generation as I have implemented it successfully for a client. I have posted a full write up of it on my blog. Feel free to comment on it here or on my blog; I will post a patch when I have a chance and if there is interest.

Article link: http://earnestberry.com/node/13

Coding Standards and Performance Optimization