Hi,
I don't remember where else I found this being discussed, but it was, somewhere..

The problem:
views_get_applicable_views() is used by modules like EVA or Views attach to find views and views displays with a specific configuration setting.

To do this, it uses views_get_all_views(), which adds a lot of unnecessary performance overhead.

In fact, these modules only need to find all views displays of a specific display plugin - such as "node_content", "eva" or "block".
The next step would be to load the display plugin settings, which determine if the view is to be displayed or not.
Only then if the view is really to be displayed, it can load the rest of the display settings, for this one views display.

It would be easy to fetch all displays of a given display plugin from the database, as this is a separate column.

Unfortunately, some of the views might live not in the database, but in code only, via hook_views_default_views(). These would have to be fetched separately.
And finally, the configuration is all in one big serialized variable in the db, so it can only be fetched all at once.

-----------

Solution, part I:
Provide a function to fetch all views displays for a given display plugin.
This function will look in the table column for all db-dwelling views displays, and then do the tough way for all code-dwelling displays.

Solution, part II:
Cache the display plugin and plugin settings for all views displays, including those that live in code.

-------------

And here it is, in the code itself :)

<?php
function views_get_applicable_views($type) {
  // @todo: Use a smarter flagging system so that we don't have to
  // load every view for this.
  $result = array();
  $views = views_get_all_views();
?>

Totally agree with this guy who wrote the comment :)

Comments

joachim’s picture

Component: Miscellaneous » Code

The thing with solution 1 is that we're using ctools_export_crud_load_all() which doesn't allow for any kind of conditions on what's loaded -- it just loads everything.

Solution 2 might be a better bet -- views_get_applicable_views could keep a cache of a PHP array that's:

display id =>
display type,
view name,

donquixote’s picture

we're using ctools_export_crud_load_all()

And that's a requirement? We can't use something else?
There is a D6 module I created locally, a replacement for views_attach where displays are fields in nd/ds, which does exactly that to find its own views displays. It does work.

cache of a PHP array

What about, we have multiple cache variables, one for each display type?
So views_get_applicable_views() does only load stuff for one display type at a time..

Or, if we already use a normal cache mechanism, we don't even need to move to display type as a criterion, we can keep the $type criterion.

Of course, with this solution, we still load all views on cache refresh. This might be acceptable, but still annoying during development. Think of menu_rebuild(), etc.