Extreme Slowdown in FPC 3.0.x versus 2.6.4, DBGrid Sqlite3 master-detail
Original Reporter info from Mantis: jbthiel
-
Reporter name: JBThiel
Original Reporter info from Mantis: jbthiel
- Reporter name: JBThiel
Description:
I am working to migrate a Lazarus App to newer FPC 3.0.x
From prior FPC 2.6.4, and Lazarus versions 1.2.x, 1.4.x, 1.6.x, 1.8.x
on Linux GTK2
Testing described below is all with Lazarus 1.8.4 which compiles with both FPC 2.6.4 and 3.0.4
App design is master-detail DBGrids, on SQLite v3.8.5 database, with associated SQLConnections, Datasets, etc.
PROBLEM: With FPC 3.0.4, master-detail DBGrid is extremely much slower, the app is unusable.
To illustrate:
Cursor Next Line (Down arrow) in a master DBGrid, the cursor should move and detail grid update.
With FPC 2.6.4 is instantaneous.
With FPC 3.0.4 this takes about 1+ second.
During the delay, it's 100% usage on a single cpu, and the whole app is frozen, menus don't work, etc.
When it comes back, the cursor moves and detail grid updates, simultaneously (as expected), and
correct data is displayed.
Does not seem to be dependent on how many records are in the detail.
Also, I noticed if you key Next Line 2x, the delay will be 2x, and the final update will show the 2nd line down.
and likewise 3x, 4x, etc. Also note PgDown takes same amount of time as NextLine.
(ie. the delay seems specifically related to time for the detail grid/query to track the newly selected master row)
Additional information:
I have done some valgrind Profiling, which does not show obvious runaway functions that I can distinguish from normal operation.
It's basically all idle loop and handle message, context dispatch, widget events, alloc, free, etc.
I have 2 suspect areas so far:
-
Possible Bug(s) in FCL event handlers, spurious/repeated events, exceptions, etc.
-
Comparing execution profile of FPC 304 with 264, I see considerably more ANSISTRING manipulations.
I noticed there are many changes in the FCL Sqlite code for 3.0.4, like sqlite3conn.pp and sqlite3.inc,
and all Sqlite external function declarations with pchar were changed to pansichar.
Also AnsiStrings now have Unicode/CodePage support in FPC 3.
Do I need to make some settings to account for this? I'm unfamiliar with codepage and basically ignoring it.
In particular, when profiling these functions stand out for FPC 304, are not in FPC 264:
( 4.06%) ???:SYSUTILS_$$_INTERNALCHANGECASE$ANSISTRING$TSYSCHARSET$LONGINT$$ANSISTRING
( 1.55%) ???:fpc_ansistr_compare_equal
( 1.48%) ???:CWSTRING_$$_UPPERANSISTRING$ANSISTRING$$ANSISTRING
Instead of the last one above, FPC 264 has
( 1.51%) ???:SYSUTILS_UPPERCASE$ANSISTRING$$ANSISTRING
REPORT is two-fold:
-
What is going wrong, what is the bug, what changed in FPC or FCL 3.0.x that could be causing such extreme performance drop?
(also, should I upgrade my Sqlite version, from 3.8.5, which is somewhat older)
-
I would like to provide further detail, but what debugging techniques can be used for this kind of problem?
How can I find and measure effects like spurious/repeated events, excessive ansistrings, etc?
The results are all "correct".
If I catch specific events and step thru the debugger, each step basically happens "fast".
Just that overall it is 10x or 100x slower.
How can I find what it's doing during these 1+ second freezes?
like profile exactly all function calls between key NextLine until it refreshes all grid displays.
Mantis conversion info:
- Mantis ID: 38118
- OS: Linux GTK2
- Platform: FPC 3.0.4 vs FPC 2.6.4
- Version: 1.8.4
- Monitored by: » Vincent (Vincent Snijders)