4 ms·
Your Go code uses "defer" in a for loop, which could be a performance bottleneck. The deferred function call doesn't run until the saveToDb function returns. A
by lobster_johnson 9y ago
Your Go code uses "defer" in a for loop, which could be a performance bottleneck. The deferred function call doesn't run until the saveToDb function returns. A simple fix would be to reuse the rows variable and put the defer outside the loop.
I believe it might, depending on the database driver, also cause another issue. Since you're not closing the rows right away, and not even consuming the rows, this may force the driver to mark the internal connection as busy until the defer runs, meaning the next database call would have to open a new connection. Try closing the rows as soon as you can.
If you don't expect any results, you can also use Exec instead. Then there's nothing to close.
- noncoml 9y agoI keep the habit of deferring immediately so I don’t forget later if the fucnction gets long. But I see what you mean, on this case, inside the loop, is really bad idea. Will try with Exec and without the defer and see if it makes a noticeable difference. The driver is the MySQL one for what’s worth it. Postgres was a bit slower.
- noncoml 9y agoJust to update that you where right. Without the `defer` now golang is as fast as erlang. Exec vs Query didn't make a difference. Yet another update: things get really interesting when I run wrk. I don’t want to spoil it for you. I can let you try it ;)
- egisspegis 9y agoPlease spoil it for us. I would love to see results, but can't run wrk myself at the moment.