here<\/a>.<\/p>[\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.0.7″][et_pb_column type=”4_4″ _builder_version=”4.0.7″][et_pb_text _builder_version=”4.0.7″]BenchmarkLogrus-16 \t 358696 3222 ns\/op\nBenchmarkLog-16 \t 4048160 330 ns\/op\nBenchmarkLogrusMap-16 \t 331330 3523 ns\/op\nBenchmarkLogMap-16 \t 638674 2005 ns\/op\nBenchmarkLogrusMapSmallMembers-16 \t 326095 3625 ns\/op\nBenchmarkLogMapSmallMembers-16 \t 624159 1935 ns\/op\nBenchmarkLogrusCallerReport-16 \t 181448 6657 ns\/op\nBenchmarkLogCallerReport-16 \t 1246078 1024 ns\/op\n<\/pre>[\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.0.7″][et_pb_column type=”4_4″ _builder_version=”4.0.7″][et_pb_text _builder_version=”4.0.7″]The built-in log parser was able to beat out logrus by a factor of 10:1 when it comes to logging pure text via the Print<\/code> function call. As the complexity increases, Logrus gains traction against the build-in package. When logging a map, Logrus managed to get all the way down to a 1.75:1 ratio. Now, I wonder if Logrus would be able to beat out the default logger if we leverage this to its advantage. So, I put it in the most minimal mode I could find, and then ran it on a map with 1000 members.\u00a0<\/p>[\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.0.7″][et_pb_column type=”4_4″ _builder_version=”4.0.7″][et_pb_text _builder_version=”4.0.7″]BenchmarkLogrusBestCase-16 \t 1518 759788 ns\/op\nBenchmarkLogBestCase-16 \t 1750 683142 ns\/op\n<\/pre>[\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.0.7″][et_pb_column type=”4_4″ _builder_version=”4.0.7″][et_pb_text _builder_version=”4.0.7″] Sadly, it seems like the default logger will always have a slight performance advantage over Logrus. The best result I was able to produce was a 1.1:1.0 ratio, which isn’t bad. However, this was done under very artificial conditions, having all of the features disabled. From the results, it is fairly safe to say that the difference in performance mainly results from the extra bells and whistles provided by the library. <\/p>[\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.0.7″][et_pb_column type=”4_4″ _builder_version=”4.0.7″][et_pb_text _builder_version=”4.0.7″]
Personally, despite the extra overhead, I have found the additional features to be incredibly useful. Pluggable formatting makes it extremely easy to be compliant with any log analysis platform. Additionally, the ability to have different verbosity levels is incredibly helpful for reducing the cost of your log ingestion pipeline. <\/p>[\/et_pb_text][\/et_pb_column][\/et_pb_row][\/et_pb_section]\n\n\n","protected":false},"excerpt":{"rendered":"","protected":false},"author":1,"featured_media":464,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"on","_et_pb_old_content":"\n
<\/p>\n\n\n\n
Advantages<\/h2>\n","_et_gb_content_width":""},"categories":[6],"tags":[9,12,11,10],"yst_prominent_words":[139,95,130,140,92,138,93,131,137,136,129,97,127,99,133,82,128,134,132,135],"yoast_head":"\nLogrus; a structured logger for Go - Module Safari<\/title>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\t\n\t\n\n