### Navigation

- index
- modules |
- next |
- previous |
- structlog documentation »

# Performance

`structlog`‘s default configuration tries to be as unsurprising and not confusing to new developers as possible. Some of the choices made come with an avoidable performance price tag – although its impact is debatable.

Here are a few hints how to get most out of `structlog` in production:

1. Use plain dicts as context classes. Python is full of them and they are highly optimized:

       configure(context_class=dict)

   If you don’t use automated parsing (you should!) and need predicable order of your keys for some reason, use the key_order argument of `KeyValueRenderer`.

2. Use a specific wrapper class instead of the generic one. `structlog` comes with ones for the Python Standard Library and for Twisted:

       configure(wrapper_class=structlog.stdlib.BoundLogger)

   Writing own wrapper classes is straightforward too.

3. Avoid (frequently) calling log methods on loggers you get back from `structlog.wrap_logger()` and `structlog.get_logger()`. Since those functions are usually called in module scope and thus before you are able to configure them, they return a proxy that assembles the correct logger on demand.

   Create a local logger if you expect to log frequently without binding:

       logger = structlog.get_logger()
       def f():
          log = logger.bind()
          for i in range(1000000000):
             log.info('iterated', i=i)

4. Set the cache_logger_on_first_use option to True so the aforementioned on-demand loggers will be assembled only once and cached for future uses:

       configure(cache_logger_on_first_use=True)

   This has the only drawback is that later calls on `configure()` don’t have any effect on already cached loggers – that shouldn’t matter outside of testing though.

### Navigation

- index
- modules |
- next |
- previous |
- structlog documentation »