Excellent! Great to see that it’s resolved.
1 Like
so there is no more SQLite problem? only threading ?
He may not think so, but I do. Web 2.0 TPLM was unusably slow without changing the design from Web 1.0. I profiled, saw slowdowns with selects, and had to rework things to use Active Record significantly less.
1 Like
I can’t say there’s definitely not a problem, or even that what I experienced isn’t a bug. The newer SQLite library is to blame for the SQL performance problem I experienced. I was able to solve it with a small tweak to some of my statements. See My app is extremely slow in 2025r2 - #61 by Thom_McGrath
The change I made lines up with the SQLite documentation, which makes me believe it should not have been performing as well as it did previously.
Tim may still be right, but it’s not something I’ve experienced.
1 Like
Just for the sake of clarity about the SQL feature involved:
The UNION vs UNION ALL clause causes a theoretically MASSIVE difference weighting against UNION (without ALL).
The difference is directly proportional to the number of the records involved, and basically it is the difference of a SELECT DISTINCT * FROM TABLE and SELECT * FROM TABLE. One needs to test each record before inserting it in the final result set to avoid 2 clone records (repetitions) and the other just blindly adds the records to the set… very fast.
Right. In my case I wanted the UNION ALL behavior anyway. But I suspect the old code with UNION was only fast due to a bug.