I invoke it from a subdir of a non-multisite drupal and it works from anywhere. Great!

1. I need to know how this is done cause I need it for the autocomplete stuff I am into now.
Especially I am trying to think of a FAST way to get the drupal root dir .

2. If we have a multisite install do we always need to supply the -l ? What if we are in the multisite dir - are we detected there?

CommentFileSizeAuthor
#3 timing.patch1.33 KBmoshe weitzman
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

moshe weitzman’s picture

1. well, you can ask for your drupal root with drush_get_context('DRUSH_DRUPAL_ROOT'). If that returns NULL, you can bootstrap just enough with drush_bootstrap('DRUSH_BOOTSTRAP_DRUPAL_ROOT'). The guts are in drupal_locate_root().

2. We do auto-detection in the absence of -l. See drush_site_path().

rsvelko’s picture

dr status

and

dr eval "print drush_get_context('DRUSH_DRUPAL_ROOT') . \"\n\" "

and

dr eval "print drush_bootstrap('DRUSH_BOOTSTRAP_DRUPAL_ROOT')"

take about 0.8 - 0.9s on my very fast server - which is unacceptable for an autocomplete routine ... will dig into drupal_locate_root(). and drush_site_path().

Maybe the answer would be to duplicate the algorhytm of those funcs with bash tools like find, dirname and ls .. . and some if-checks

moshe weitzman’s picture

Status: Active » Needs review
FileSize
1.33 KB

dr eval and dr status do a full bootstrap before anything else so those metrics are not valid at all.

try out the attached patch. it adds a microtime(TRUE) at the top of drush.php and again in every drush_log() call. you need to run with -v 2 in order to see them. for me, it takes 11ms to bootstrap to CONFIGURATION phase.

perhaps this patch is useful - feedback welcome.

rsvelko’s picture

it takes 11ms to bootstrap to CONFIGURATION phase. - nice

my metrics measure the whole command

It turns out like this :

$ dr status -v 2
Start: 50.79
Found command: status 50.82 [bootstrap]
Drush bootstrap phase : _drush_bootstrap_drupal_root() 50.82 [bootstrap]
Initialized Drupal 6.10 root directory at /var/www/vhosts/freizeitpark.co.at 50.83 [notice]
Drush bootstrap phase : _drush_bootstrap_drupal_site() 50.83 [bootstrap]
Initialized Drupal site default at sites/default 50.84 [notice]
Drush bootstrap phase : _drush_bootstrap_drupal_configuration() 50.84 [bootstrap]
Drush bootstrap phase : _drush_bootstrap_drupal_database() 50.84 [bootstrap]
Successfully connected to the Drupal database. 50.84 [bootstrap]
Drush bootstrap phase : _drush_bootstrap_drupal_full() 50.85 [bootstrap]
Drush bootstrap phase : _drush_bootstrap_drupal_login() 51.63 [bootstrap]
Drupal Root : /var/www/vhosts/freizeitpark.co.at
Drupal version : 6.10
Site Path : sites/default
Site URI : http://default
Database Driver : mysqli
Database Hostname : localhost
Database Username : freizeitpark
Database Name : freizeitpark
Database Password : 9wXyVqYe266qjQvm
Database : Connected
Drupal Bootstrap : Successful
Drupal User : Gast

so upto _drush_bootstrap_drupal_ful it is like 6ms on my srv.

but _drush_bootstrap_drupal_login takes 1s ..

so how do I get the info in the completion file via a drush call that does not do _drush_bootstrap_drupal_login but gives me what I want ??

how do I use drush to tell me this info fast? (dig into drupal_locate_root(). and drush_site_path(). ?? )

moshe weitzman’s picture

The log message actually comes before the bootstrap happens so it is FULL that takes 1 sec.

I would try to write a command that bootstraps up to DATABASE and then do a query to the system module for all active modules. Then do a file_scan_directory on those dirs to find all *.drush.inc files.

if you needed a little faster, skip the query for active modules and just include all command files that are in sites/all/modules and sites//modules. I think current multi-site can be learned by conf_path() or something.

rsvelko’s picture

the main autocomplete issue holds the v0.2 code now - which like 0.1 uses the find all .info files method with bash find.

If the database way turns out to be slow we will just scan for files and not care for enabled/disabled in auto-complete - unless someone comes with a better idea.

But in order to know exactly where to scan with "find" - I need the drupal root .

note: if autocomplete gives you incorrectly : (due to us seeking fast-to-develop solutions and high-performance auto-complete )
- a not enabled module when you try 'drush disable' just because it gives you ALL modules
- a module residing in sites/example1.com/modules/ when you use 'drush -l example2.com enable ' or 'drush enable' (sites/default site)

will you be angry or get hurt?

I think you will be fine cause drush enable/disable commands will fail and tell you that there is no such module ... or it is already enabled ...

Further - if someone needs to see if sth is enabled - better use the listing command statusmodules that we are polishing now...

moshe weitzman’s picture

I would not be angry or hurt. You can probably skip the DB query if needed.

moshe weitzman’s picture

any progress here?

I think this is the minimum you need. It will be very fast:

drush_bootstrap(DRUSH_BOOTSTRAP_DRUPAL_SITE);
$drupal_root = drush_get_context('DRUSH_DRUPAL_ROOT');
rsvelko’s picture

Status: Fixed » Needs review

I am not sure how to call this from bash. Please help. Should I make a new drush command or include some of the drush .inc files in a .php script ?? Maybe this will be how the proto-autocomplete backend will be born to life?

PS. I can use the --backend option with "drush help" for now.

moshe weitzman’s picture

Status: Needs review » Fixed

I just committed a different implementation. The command list is now just `drush help --pipe`. should be fast.

Lets discuss other topics in the autocomplete issue.

Status: Needs review » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.