SQLite extremely slow via C-API - sqlite

Question

Using SQLite 3.19.2, I'm running into an odd situation.
One of the queries my application performs takes an enormously long time (100+ seconds) when running inside my app. Using the sqlite3 shell, the same query takes 0.5s.
I'm using a custom build of SQLite, statically linked into my app. The version of the shell is from my custom compilation, so this isn't an issue with the compilation.
I was using multiple threads however I've since managed to reproduce this issue single-threaded.
Using perf I've determined that the majority of the CPU time is spent in sqlite3VdbeExec and not in any of my code (for instance code that reads the fields of each returned row.)
The query is sqlite3_prepare_v2'd with bound parameters. I've reproduced the query below as well as a similar query that doesn't exhibit the performance problem.
Has anyone else seen anything like this?
SLOW QUERY (100+s in the app, 0.5s in the shell):
SELECT DISTINCT
Track.*
FROM
TrackGenres,
TrackFirstArtist,
Track
WHERE
TrackFirstArtist.id = Track.id AND
TrackGenres.id = Track.id AND
TrackGenres.genreID = 328
ORDER BY
(CASE WHEN 1 = 1 THEN TrackFirstArtist.artistName COLLATE ENGLISH END) ASC,
(CASE WHEN 1 != 1 THEN TrackFirstArtist.artistName COLLATE ENGLISH END) DESC
LIMIT 50
OFFSET 0;
QUERY PLAN (the plans are identical for whether run in the app or in the shell):
2 0 0 SEARCH TABLE TrackGenre USING COVERING INDEX sqlite_autoindex_TrackGenre_1 (genreID=?)
3 0 1 SEARCH TABLE WorkGenre USING COVERING INDEX sqlite_autoindex_WorkGenre_1 (genreID=?)
3 1 0 SEARCH TABLE TrackWork USING COVERING INDEX sqlite_autoindex_TrackWork_1 (workID=?)
1 0 0 COMPOUND SUBQUERIES 2 AND 3 USING TEMP B-TREE (UNION)
4 0 0 SCAN TABLE TrackArtist USING INDEX idx_TrackArtist_trackID
4 1 1 SEARCH TABLE Artist USING INTEGER PRIMARY KEY (rowid=?)
0 0 0 SCAN SUBQUERY 1
0 1 2 SEARCH TABLE Track USING INTEGER PRIMARY KEY (rowid=?)
0 2 1 SEARCH SUBQUERY 4 USING AUTOMATIC COVERING INDEX (id=?)
0 0 0 USE TEMP B-TREE FOR DISTINCT
0 0 0 USE TEMP B-TREE FOR ORDER BY
SIMILAR QUERY (0.5s in app, 0.5s in shell):
SELECT
COUNT (Track.id)
FROM
TrackGenres,
TrackFirstArtist,
Track
WHERE
TrackFirstArtist.id = Track.id AND
TrackGenres.id = Track.id AND
TrackGenres.genreID = 328 AND
( TrackFirstArtist.artistName >= 'a' AND TrackFirstArtist.artistName < 'b' );

Answer 1

I believe this is a bug in SQLite. I tracked the problem down to the CASE statements in the ORDER BY clause when using the query in a prepared statement.
When I removed one or the other of the statements, the query ran quickly again. The collation didn't make any difference.
This doesn't seem to be a general issue with prepared statements, I have other queries with a similar structure and they work properly. As such, I've been unable to create a simple, reproducible example that illustrates the problem.
Ultimately I had to solve this by replacing the variables in the query manually to avoid the use of a prepared statement.