Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 4 of 4 total |
FieldByName Speed |
Mon, Apr 9 2012 8:34 PM | Permanent Link |
Lance Rasmussen Jazzie Software Team Elevate | I attached an XE2 project in the binaries.
Following an article, I thought it was interesting to see speed differences in handling things such as bulk insertions or performance hits when using fieldbyname. Curious to see what you've come up with to speed up the handling. Lance |
Thu, Apr 12 2012 12:52 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Lance,
<< Following an article, I thought it was interesting to see speed differences in handling things such as bulk insertions or performance hits when using fieldbyname. Curious to see what you've come up with to speed up the handling. >> The problem with FieldByName() is that it is defined at the TDataSet level, so that limits what I can do in terms of speeding things up at a core level. I could try "hiding" the ancestor method in our descendant components, but that only works in situations where a dataset reference isn't cast or passed as a TDataSet ancestor instance. This is one of the reasons why I always recommend using persistent TFields, if at all possible. If that isn't possible, then your technique of saving references to each TField returned by FieldByName() and then using those references instead is a very good way of avoiding the hit of FieldByName() in an intensive section of DB code. Thanks, -- Tim Young Elevate Software www.elevatesoft.com |
Thu, Apr 12 2012 7:12 PM | Permanent Link |
Lance Rasmussen Jazzie Software Team Elevate | It was something that came up with Zarco on About.com for Delphi, pointing out about 4-5 ways to handle the situation. His sample app used a CDS in memory, so I thought I would EDB it for grins.
I'm refactoring some of my code to save the references to TFields, but obviously not fun. But when you get a point of a large amount of data, little things like this help. BTW - Wasn't complaining about EDB's speed. Anything done by you for speed improvements that help the majority is always appreciated and I've been real happy with performance. I figured this was more big picture for all to see and a way people can take it to the next level, when important. Lance "Tim Young [Elevate Software]" wrote: The problem with FieldByName() is that it is defined at the TDataSet level, so that limits what I can do in terms of speeding things up at a core level. I could try "hiding" the ancestor method in our descendant components, but that only works in situations where a dataset reference isn't cast or passed as a TDataSet ancestor instance. This is one of the reasons why I always recommend using persistent TFields, if at all possible. If that isn't possible, then your technique of saving references to each TField returned by FieldByName() and then using those references instead is a very good way of avoiding the hit of FieldByName() in an intensive section of DB code. |
Wed, Apr 18 2012 12:54 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Lance,
<< BTW - Wasn't complaining about EDB's speed. Anything done by you for speed improvements that help the majority is always appreciated and I've been real happy with performance. I figured this was more big picture for all to see and a way people can take it to the next level, when important. >> No problem at all. Thanks, -- Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Sunday, May 5, 2024 at 07:30 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |