# Looking up tag property against the config provider

**URL:** <https://forum.inductiveautomation.com/t/looking-up-tag-property-against-the-config-provider/6845>\
**Category:** Module Development\
**Created:** [July 10, 2013, 9:56pm UTC](https://forum.inductiveautomation.com/t/looking-up-tag-property-against-the-config-provider/6845 "2013-07-10T21:56:16Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![idelamer](https://avatars.discourse-cdn.com/v4/letter/i/e5b9ba/32.png) [@idelamer](https://forum.inductiveautomation.com/u/idelamer)\
**Post date:** [July 10, 2013, 9:56pm UTC](https://forum.inductiveautomation.com/t/looking-up-tag-property-against-the-config-provider/6845/1 "2013-07-10T21:56:16Z")

</div>

This seems to be new behavior since I upgraded to 7.6.x

When I’m browsing the Tag tree (e.g. in Designer), and Tag properties are browsed, I get the following warning in the console for properties which have not been defined:

```auto
Looking up tag property 'XXXX' against the config provider. Potentially inefficient operation.
```

By debugging it looks like there is a search for EntityId and then search in the database.

The tag configuration is held by a TagDefinition and a TagBasedConfigProvider(TagDefinition).

Any suggestions how to avoid this? It overflows the console and it is very slow.

Cheers  
Ivan

---

<div class="post-metadata">

**Author:** ![Colby.Clegg](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/colby.clegg/32/3282_2.png) [@Colby.Clegg](https://forum.inductiveautomation.com/u/Colby.Clegg)\
**Post date:** [August 22, 2013, 8:31pm UTC](https://forum.inductiveautomation.com/t/looking-up-tag-property-against-the-config-provider/6845/2 "2013-08-22T20:31:51Z")

</div>

Hi,

That message is only logged when your overall logger for the tag provider is set to trace. So, I’d say just turn off the logger. (The logging of all of the messages certainly is slowing down your browse)

If it’s a TagBasedConfigProvider, the lookup won’t actually be slow (hence the “possibly”). All of _our_ tags use a different provider that goes against the internal database, which _is_ slow, which is why we have that message.

Regards,