Hacker News new | past | comments | ask | show | jobs | submit login

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.




Just 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 ;)


Please spoil it for us. I would love to see results, but can't run wrk myself at the moment.


I get 2x more requests on erlang


OK, I was unfair to golang again. Turns out it needs a bit more tuning "db.SetMaxOpenConns(10)" and now golang and erlang are on par.


I 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: