improve datetime perf

[trim21]

benchmark with simple logger.info("hello {}", "b") with os.devnull sink, from 44s to 20s

ref: #1201

[trim21]

looks like we are still running tests on 3.5, so we can't add inline typing or use f-string ...

[trim21]

also， why aware_now use time module instead of using datetime_.now.astimezone and combine it as datetime？

[trim21]

I think we can also include a fast path for default datetime format

[Delgan]

Hey @trim21.

Thank you for your work in improving Loguru's performance.
I never realized that datetime formatting was so costly. Good catch. Caching a pre-computed formatter is a simple and excellent idea to reduce the overhead.

I've done a few experiments and I think we can go even further. We do not need to repeatedly parse the tokens with the regex. We can build a formattable string associated with runtime formatting functions.

See the diff here: 80f05fd

Here are a timeit command using a non-default format:

$ python -m timeit -s "from loguru import logger;logger.remove();logger.add(lambda _: None, format='{time:YYYY-MM-DD HH:mm:ss.SSSSSS Z}');logger.info('Hello')" "for _ in range(10):logger.info('Hello')"

Results:

# master
500 loops, best of 5: 426 usec per loop

# trim21/datetime-perf
1000 loops, best of 5: 225 usec per loop

# Delgan/faster-datetime
2000 loops, best of 5: 160 usec per loop

It's arguably an almost negligible improvement on what you've already done, but it pushes optimization further without adding much complexity.

Do you mind if I merge this commit instead? Do you think it could be improved?

[trim21]

Looks fine