EFQ calls field_info_field() too liberally

It's not confused at all. ->condition('router_path', $paths, 'NOT IN') in menu.inc causes $field = field_info_field($specifier); to fire in Drupal\field_sql_storage\Entity\Tables::addField trying to figure out whether router_path is a customizable (field API) field or not. Why is this a problem?

So yeah, the current use of field_info_field() within EFQ is a perf problem, really doesn't play well with the FieldInfo cache strategy, and this shows badly with "Field API -> CMI" : #1735118-149: Convert Field API to CMI

What EFQ really does is "is that $name a Field API field ?". Only if yes, it needs the actual $field.
But the 1st question is "does this field exist ?", and for that it should use field_info_field_map().

Hopefully this is along the right lines. Entity query tests still pass locally.

New version this adds a lightweight mapper to get fields by id not sure if this is needed by given the context it seems to make sense.

Doxygen was wrong in last patch.

Thanks for tackling this, @marcingy !

I'm not sure the part about ids is really needed.

The problematic part of the addField() method is loading a field definition (thus hitting config) just to check whether some string is a field name or not (in which case we consider it's an entity property).
I.e. those lines in HEAD :

      else {
        $field = field_info_field($specifier);  // <- This.
       }
       if ($field) {
         // Do something relevant for a Field API field.
       }
       else {
         // Do something relevant for an entity property)
       }

I'd think the case when $specifier is "id:[something]", that is dealt with be the lines just above that snippet, is not ambiguous and "[something]" is then *always* a field ID. Then, no need to check a field map, calling field_info_field_by_id() is fine.

This could use some confirmation from @chx, though, cause this 'id:' syntax doesn't seem to be documented in Drupal\Core\Entity\QueryInterface ?

Other approach : entity properties are defined in code, and field API fields are defined in config. So it should be much faster to check if something is an entity property first, and only then check if it's a field ?

Re-titling.

The id: is only for purge purposes and so is not documented. The whole field purge needs a new approach...

I re-read the issue a few times and wrote an entirely new patch, using marcingy's patch as inspiration only.

I can confirm that field_read_field() is only called for actual fields with this patch. Not sure if it should be called at all, I guess direct access to a certain field isn't cached?

Given that, not sure if I can RTBC this patch like that, today is the big day for Field API so swentel will very likely show up during the day and can hopefully answer that question.

#13 looks just fine, and #1735118: Convert Field API to CMI doesn't touch this file at all, so this shouldn't conflict.
Thanks @chx !

Committed e0a111a and pushed to 8.x. Thanks!