GRDB appears to encourage Codable which is very slow. It does not require it though and there are some alternatives, some of which are also slow. ("Slow" can still mean "fast enough", depending on the user.)

SQLiteData uses this library which uses Swift macros to generate performant interfaces to schema statically at build time: https://github.com/pointfreeco/swift-structured-queries

The alternative I've seen for doing this with GRDB seemed more cumbersome and lacks community adoption: https://github.com/Jasperav/GRDB-ORM You must define schema and queries in an unusual external file that a Rust tool transforms for you.

There is also this library which does not use GRDB but takes a similar approach to SQLiteData though you have to run a program that generates the bindings outside of your normal build: https://lighter-swift.github.io/documentation/lighter/perfor...

▲

groue 3 days ago | parent | next [-]

Yes. GRDB encourages Codable because the user can profit from the code generated by the compiler, and this implies that database values are accessed by column name, on top of the Codable runtime, and those layers have a high cost. When necessary it is possible to access database values by position, and in this case GRDB achieves speed of light (performance nearly identical as raw SQLite).

▲

wahnfrieden 3 days ago | parent [-]

From my understanding this is a sample of the database values by position approach: https://github.com/Lighter-swift/PerformanceTestSuite/blob/m...

That approach benchmarks at 2.2x the duration of StructuredQueries (45% as fast): https://github.com/Lighter-swift/PerformanceTestSuite/blob/8...

18.819s vs 8.511s

So it appears that there is lightning-fast and lighting-faster.

Of course aside from comparing the dev ergonomics (138 vs 33 lines for the respective benchmarks), either may be fast enough depending on the use case.

BTW I did also see some discussion in swift-evolution about a future replacement for Codable but haven't tracked its progress. I hope they do because Codable is very convenient but tragically slow.

▲

helge5 3 days ago | parent [-]

Yes, GRDB even w/ manual help is obviously not as fast raw SQLite. As much respect I have for the author "performance nearly identical as raw SQLite" is incorrect. Lighter also achieves some of the performance characteristics by avoiding allocations for bound parameters (such being statically generated). I didn't look into SharingGRDB yet, but it seems like those macros could accomplish similar performance, the other way around (Lighter works on the SQLite DB schema). What I'm not entirely sure of yet is why it even sits on top of GRDB in the first place, instead of just doing the SQLite parts itself. Marketing I suppose.

	▲	stephencelis 3 days ago \| parent [-]
		> Marketing I suppose. Nope. And not sure where you get that idea. This release even involved a rename away from including "GRDB." When 0.1 of the library was released, it was a simple adapter between our Sharing library and GRDB, thus the name SharingGRDB. As our needs grew, the tool evolved significantly, and both the Sharing component and GRDB have become more of an implementation detail. In the future we will consider supporting any SQLite adapter, even your libraries ;)

▲

dgllghr 3 days ago | parent | prev [-]

Now I understand. Thanks!