Anonymous | Login | Signup for a new account | 2019-02-18 00:03 CET |
Main | My View | View Issues | Change Log | Roadmap | Docs |
Viewing Issue Simple Details [ Jump to Notes ] | [ View Advanced ] [ Issue History ] [ Print ] | ||||||
ID | Category | Severity | Reproducibility | Date Submitted | Last Update | ||
0006275 | [JEDI VCL] 00 JVCL Components | major | always | 2014-04-22 17:42 | 2015-09-14 13:20 | ||
Reporter | bazilio | View Status | public | ||||
Assigned To | AHUser | ||||||
Priority | normal | Resolution | fixed | ||||
Status | resolved | Product Version | Daily / GIT | ||||
Summary | 0006275: Very poor performance of JvMemoryData on large datasets | ||||||
Description |
We have heavy application for TJvMemoryData. It have few dynamically JV memorydataset with 100-200 fields and 10-100 rows. During perfoformance tuning of our application we reached following strange behavior of TJvMemory. Direct access via TField of first fields is fast but access to last fields is very slow. After investigation I found that the TJvMemoryData.FindFieldData(Buffer: Pointer; Field: TField): Pointer; contains very suspicious code var Index: Integer; DataType: TFieldType; begin Result := nil; if Length(FCopyFromDataSetFieldDefs) > 0 then Index := FCopyFromDataSetFieldDefs[Field.Index] else Index := FieldDefList.IndexOf(Field.FullName); IndexOf(Field.FullName)!!!!! instead of access through Field.Index/ I wrote very little patch to avoid this. Test project attached. Any comments? |
||||||
Additional Information | |||||||
Tags | No tags attached. | ||||||
Attached Files |
![]() |
||||||
|
Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |