Log On
Embarcadero Home
Watch, Follow, &
Connect with Us
Share This
QualityCentral
Communities
Articles
Blogs
Resources
Downloads
Help
QualityCentral
Delphi-BCB
Database
ADO
Azure
Blackfish SQL
CAB File
Config Maintenance
Core VCL
Aggregates
Blobs
Cached Updates
Client Constraints
Filters
Indices
Lookup
Master/Detail
Navigation
Ranges
Transactions
Data Access Controls
Data Aware Controls
Data Dictionary
Data Explorer
Data module
Database Tools
DataSnap
DBExpress
dbExpressCore
Debug Layer
Decision Cube Controls
Drivers
Environmental
Fields Editor
Form Wizard
Int'l Lang Driver
Performance
Remote Data Module
Sessions
Super Join
System Level Info
TField
TParams
You are not logged in.
Help
Print
Public Report
Report From:
Delphi-BCB/Database/Core VCL
[ Add a report in this area ]
Report #:
75575
Status:
Open
Suggestion to improve TDataset.FindByName performance
Project:
Delphi
Build #:
21218
Version:
12.1
Submitted By:
Mason Wheeler
Report Type:
Suggestion / Enhancement Request
Date Reported:
7/6/2009 5:30:56 PM
Severity:
Commonly encountered problem
Last Updated:
3/20/2012 2:24:39 AM
Platform:
All platforms
Internal Tracking #:
278628
Resolution:
None
(Resolution Comments)
Resolved in Build:
:
None
Duplicate of:
None
Voting and Rating
Overall Rating:
No Ratings Yet
0.00 out of 5
Total Votes:
None
Description
TDataset.FindByName is well-known for its slow performance, especially in loops. Every time it's called, it runs a (slow) linear search, doing a (slow) string comparison against every field name until it finds a match. It's bad enough that it's become a common design pattern to preallocate local TField variables in functions that have to use FindByName, so the call will only have to be made once for each field.
This overhead could be alleviated quite a bit by replacing the linear search with a hashtable lookup. Add a TDictionary<string, TField> to TFields, and have TFields.FindField check it. Make sure to uppercase all the strings first, to preserve case insensitivity.
Suddenly instead of a slow string comparison multiplied by a slow O(N) search, we have a slow string-hashing operation multiplied by a much faster O(1) search.
Steps to Reproduce:
None
Workarounds
None
Attachment
None
Comments
None
View Your Reports
Search
Server Response from: ETNACODE01
Developer Tools
Blackfish SQL
C++Builder
Delphi
FireMonkey
Prism
InterBase
JBuilder
J Optimizer
HTML5 Builder
3rdRail & TurboRuby
Database Tools
Change Manager
DBArtisan
DB Optimizer
ER/Studio
Performance Center
Rapid SQL
Technical Articles
Tutorials
White Papers
Press Releases
Newsletters
Add Content (GetPublished)
Audio
Audio & Video
Video
Bugs & Suggestions (QualityCentral)
Discussion Forums
Examples (CodeCentral)
Tags
Technology Partners
Downloads
Free Trials
Registered User Downloads
Beta Programs
Add Content (GetPublished)
Articles
Blogs
Bugs & Suggestions (QualityCentral)
Discussion Forums
Examples (CodeCentral)
Member Services
About
Connect with Us