MySqlSharp
MySqlSharp copied to clipboard
neuecc
Why a sync api?
Why not drop the sync api completely? No compromise on speed for an api that should not exist in the first place. Also, good work! ill be testing some of your other projects, they all seem really cool.
Basically sync is faster than asynchronous because has no overhead of Task, etc. The advantage of asynchronous is scalability. The worst is that sync is a wrapper of async. If existing application is builded sync, requires sync specialized code. Or batch etc, single(or parallel(Parallel.For, etc)) code sync has advantage.
For example, Booksleeve(previous version of StackExchange.Redis) has only async but StackExchange.Redis has both sync and async.
Sorry for delayed develop. I'm focusing MySQL's text protocol parsing and prototype for that, I've built Utf8Json. https://github.com/neuecc/Utf8Json/#text-protocol-foundation There code will be improve for MySqlSharp.
Faster in what context? if u can block threads for IO, you are not in need for a super fast driver anyway. If you are serving a few hundred queries per second, sync IO is already a problem, and if not, why would you need something faster if you are not serving any meaningful amount of requests? I am only making a case to drop the sync api because it increases the amount of code by a lot, and we should not encourage the use of the sync apis anyway.
Async solves everything, is not. It has been known since the release of C# 5.0. If I/O is a everything of bottleneck, fast serializers and others will be unnecessary. And it was said so far. But the reality is not so.
I just think that there is no scenario that doing sync IO for a database is a good thing, and it complicates the code base quite a bit. Feel free to close the issue.
IMO, implementing async-api have higher priority than sync-api. You can provide sync-api as sync-over-async and focus on important parts of the code. Often, sync-api is used at client side so its performance (such as how much it allocates) is not important, unlike async-api.
