Change logger to use persistent_term for level checks #2356
Conversation
|
Since this PR contains bug fixes, shouldn't it be targeted for |
4793d0d
to
5dcfbb1
Compare
|
merged bug fix into maint, the rest will go into master |
|
I guess configs have to stay in ets because they need to be able to be updated without the persistent term penalty? |
|
I've not decided what to do about them yet. I may move parts of the config from ets, or maybe all of it. Updates happen very rarely so maybe it would be ok to move it all. |
|
Ah, ok. I'd argue for being in a persistent term and adding a note in the docs about what happens when updating the config. But maybe there are users who expect to be able to update that stuff constantly. |
5dcfbb1
to
2d84d86
Compare
|
I've added the handler filter to be cached in persistent_term as well. I think I'll leave the handler config out of persistent_term, as when we have decided that we should call the handler the overhead of the actual handler will overshadow the ets lookup needed to get the config. |
Move the module level config into persistent_term for faster and more scalable lookup.
Some config calls do not need the table ref any more as the data is stored in persistent_term, so no need to pass it.
9bc1dd1
to
e32837e
Compare
Move the primary and module-level checks into
persistent_term.I would also like to move the handler level checks (and possibly config) into
persistent_term, but that is not done yet.Also did some other small improvements/bug-fixes.