Looks like only transactions are "slow", where "slow" means 2ms, which is perfectly acceptable since it needs to wait for disk commit.
So the problem is that the author is using it wrong, since you only need to wait for transaction commit when you need guaranteed durability, and you only need guaranteed durability when you are communicating success to the user or some other system, which only needs to happen every frame, which is 16ms at 60fps which is plenty of time to wait for a 2ms transaction commit (network communication can also be throttled to the framerate).
So in practice all you need to do is batch writes in a single transaction per frame and there is no problem.
And of course if you don't need durability you can just keep the data in the JavaScript heap (and use inter-tab communication if needed).
Comments
Looks like only transactions are "slow", where "slow" means 2ms, which is perfectly acceptable since it needs to wait for disk commit.
So the problem is that the author is using it wrong, since you only need to wait for transaction commit when you need guaranteed durability, and you only need guaranteed durability when you are communicating success to the user or some other system, which only needs to happen every frame, which is 16ms at 60fps which is plenty of time to wait for a 2ms transaction commit (network communication can also be throttled to the framerate).
So in practice all you need to do is batch writes in a single transaction per frame and there is no problem.
And of course if you don't need durability you can just keep the data in the JavaScript heap (and use inter-tab communication if needed).