пн, 9 мар. 2020 г. в 19:36, Axel Wagner <axel.wagner...@googlemail.com>:
> IMO, there really isn't a super good answer. The simple answer is: You > need to delay the actual `fmt.Sprintf` call as long as possible. Which > generally means, that the interface you consume (to allow the user to > direct and configure logging) will need to reflect formatting and all kinds > of things that the user actually doesn't want to deal with. So it's hard to > find a good tradeoff between API simplicity and usability and not > allocating in this case. > > Another, maybe unforseen problem, is that you don't want logging to > interfere with production. It's a painful lesson to learn, that synchronous > logging can take down a production service with ease. If you want to be > prepared for that and reduce the runtime overhead of logging, you will have > to make it asynchronous. But that's fundamentally at odds with the above > goal of delaying formatting - the user will usually not expect arguments to > loggers to be used after the logging call returns. Buffering a formatted > string avoids that of course. > > Thanks! So i think that most simple case is check each time log level , and output log only if level satisfied. -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CACaajQshiJaz%2BAJ_Tm5VbTW8FDfP0QyLvzj_KCGDTAM7RpiPrg%40mail.gmail.com.
