Poor query performance with large result sets about mysql-kit HOT 7 CLOSED

I might do a stress test again later, but I'm sure the situation improved much since January. Definitely no need to keep this open.

from mysql-kit.

Further experiments show that replacing the byte-decoded UInt8 sequence -> String conversion with String(validatingUTF8:) brings up the speed to a tolerable level while reducing memory usage.

Unfortunately, one cannot assume with MySQL that the data doesn't contain ASCII NULLs inside, so it's not a viable solution...

from mysql-kit.

@vzsg I'd like to investigate this, but how do I go about verifying if the result set is leaked or not?

from mysql-kit.

I was using Xcode's Debug Navigator for tracking total memory use – if it's not a flat graph, something is wrong – then Memory Graph and Instruments to look into what's leaking.

All of this was done with a simple command line application whose only dependency was vapor/mysql.

from mysql-kit.

Any updates on this?

from mysql-kit.

No, I haven't gotten to this. Thinking we should revisit this after 2.0 comes out of beta

from mysql-kit.

We've moved to a much more efficient makeString() implementation in Vapor 2. https://github.com/vapor/bits/blob/master/Sources/Bits/ByteSequence%2BConversions.swift#L4-L10.

Going to close this issue for now since a good portion of it has been addressed and the issue of performance is pretty general. Please feel free to open a new issue for any specific performance issues.

from mysql-kit.