Performance tuning

[grigi]

Description

aiosqlite will always issue an event loop cycle, whereas changing the polling loop to block the first time only for a short time-period, and then falling back to polling, yields significant speed ups:

	Before	After	Speedup factor
Insert	94.54	945.84	10.0
Insert: atomic	143.16	2231.41	15.6
Filter: match	67100.22	94516.01	1.4
Filter: contains	80936.28	96419.78	1.2

This PR will likely cause jitter to enter the event loop, but I think the gains offset it.

[amyreese]

I'm surprised this grants such a significant speedup. Can you share the benchmark code you used, and/or add it in the tests/ directory for future reference?

[grigi]

Sure, I'll drop you some links here.
We have been using this for an asyncio ORM project: https://github.com/tortoise/tortoise-orm

I found out what was going on by starting on a set of benchmarks to get a baseline and compare it to existing ORMs. The results so far was not very pretty:
https://github.com/tortoise/orm-benchmarks

This is the snippet that showed the big improvement:
https://github.com/tortoise/orm-benchmarks/blob/master/src/tortoise/test_b.py

The way I found this limit was with me playing with the connector code here:
https://github.com/tortoise/tortoise-orm/blob/master/tortoise/backends/sqlite/client.py#L54-L69
and realised that the issue seems to be a latency issue. every single command, including the BEGIN TRANSACTION or the SELECT last_insert_rowid() which are normally instantaneous as they do no I/O, was always incurring an event-loop polling cost.
So I thought what happens if I make the get_nowait to be syncronous instead, then noticed a massive speedup. Then I decided to move it out to minimise the cost of halting the event loop all the time, and it hardly decreased at all.

Hence this PR.

[amyreese]

Excellent, I added some basic perf tests to aiosqlite, and was able to replicate the results. 😄 Thank you!