Closed deeenes closed 1 month ago
Thanks for the report.
I'd rather not do (1) or (2), but something like (3) should do the trick I think: get_logger_meta_variables
should get the explicit list of fields to look up and return, as this way it's clear what is to be looked up and not wasting resources.
For this end, we need to add a fields
param to get_logger_meta_variables
and then update the calling layout functions, e.g. the layout_glue_generator
should first extract the field names between the curly braces and pass to get_logger_meta_variables
, and this is even easier with the JSON layouts.
Would you be open to creating a PR? Otherwise, I'll try to get there in a few weeks.
I had to revert the above PR (see d2d7d58c12fb2fcd3014bda1395b1baaa703d27c for more details), so reopening the ticket to track future work.
Hello,
I was after a severe performance issue in one of my applications, and I ended up at the above mentioned function in
logger
. Within there, thegsub
call can take eventually minutes (!). It happens if, due to nested calls or large vectors or data structures in the arguments,deparse
returns a string of 10-100k characters long. Applying a regex containing many*
's is just computationally heavy.I see the reasons why this has been introduced in response to #20. I think a number of solutions are possible:
fn
orcall
and pass this information toget_logger_meta_variables
(all fields are always generated, but only these two, especiallycall
, is expensive to process)I think a combination of the second two would be a nice solution, i.e. if
call
is not required, we do nothing, otherwise we do the formatting on a truncated string. Let me know if I should make a PR.Best,
Denes