Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 8 of 8 total |
v4 questions |
Tue, Sep 22 2009 2:49 PM | Permanent Link |
"Alessandra" | Since i have some very pedantic customers, i guess i will have to justify in
some way the 10-15% of performance decrease in complex statistical processes of our management softwares after the upgrade from v3 to v4. That percentage has been observed by me after a lot of experiments, even with bigger/smaller buffers etc. (our programs run locally or in LAN, with archive-file sharing, no server, and the internal architecture is mainly based on tables, not queries). 3.30 is definitely faster than v4. What can i tell them? the indexes with v4 are more robust than v3? the repair procedure is more effective than in v3? from their point of view, obviously, they won't see anything else than a slowness, so i have to find good excuses. Any suggestion? Sandra |
Tue, Sep 22 2009 7:42 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Alessandra,
<< Since i have some very pedantic customers, i guess i will have to justify in some way the 10-15% of performance decrease in complex statistical processes of our management softwares after the upgrade from v3 to v4. >> If you can send me a project that demonstrates this slowdown, I'll be happy to profile it and tell you where the performance issues are. -- Tim Young Elevate Software www.elevatesoft.com |
Tue, Sep 22 2009 9:34 PM | Permanent Link |
"Alessandra" | Tim Young [Elevate Software] wrote:
> If you can send me a project that demonstrates this slowdown, I'll be > happy to profile it and tell you where the performance issues are. thanks for your availability, Tim, you're very kind, but unfortunately i think i am not able to setup such a demo project, since the way these statistics are designed are very specific and difficult to reproduce. Besides, the difference in processing times are clearly evident only when the user filters, from the form, a rather large number of articles/records (more than 100,000) and processing time goes up to more than 10 minutes. It's difficult to reproduce such a complex processing, involving a number of different archives, searches, etc. with a demo project. The same statistic, with the same data and same user filter, takes a bit less than 10 minutes with v3, 11'30'' with v4 and 12'30'' with v4 + encryption on the main data file to be analyzed. Anyway, my questions are still open: - the indexes with v4 are more robust than v3? - the repair procedure is more effective than in v3? and also - with v3 i found that the "locate (.. [locaseinsentive])" compared with "locate (.. [])" on the numeric field used as primary index caused sometimes a serious performance hit when using "[]". Not sure why this difference with a numeric field, but some processing took a lot of time when the locate was with [] instead of [locaseinsensitive]. Is this "bug" (or whatever you can call hit) has been solved with v4 ? Thanks Sandra |
Wed, Sep 23 2009 8:40 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Alessandra,
<< thanks for your availability, Tim, you're very kind, but unfortunately i think i am not able to setup such a demo project, since the way these statistics are designed are very specific and difficult to reproduce. Besides, the difference in processing times are clearly evident only when the user filters, from the form, a rather large number of articles/records (more than 100,000) and processing time goes up to more than 10 minutes. It's difficult to reproduce such a complex processing, involving a number of different archives, searches, etc. with a demo project. The same statistic, with the same data and same user filter, takes a bit less than 10 minutes with v3, 11'30'' with v4 and 12'30'' with v4 + encryption on the main data file to be analyzed. >> Are you using encrypted tables ? If so, then that is the reason for the difference in performance. V4 uses strong crypto, while V3 does not. << - the indexes with v4 are more robust than v3? - the repair procedure is more effective than in v3? >> The repair procedure is more effective, and the indexes are pretty much the same as with V3. << - with v3 i found that the "locate (.. [locaseinsentive])" compared with "locate (.. [])" on the numeric field used as primary index caused sometimes a serious performance hit when using "[]". Not sure why this difference with a numeric field, but some processing took a lot of time when the locate was with [] instead of [locaseinsensitive]. Is this "bug" (or whatever you can call hit) has been solved with v4 ? >> No, case-sensitivity does not matter with V4 and integer fields. As for V3, I would have to know which version you were using in order to confirm whether it was a bug or not. -- Tim Young Elevate Software www.elevatesoft.com |
Wed, Sep 23 2009 10:20 AM | Permanent Link |
"Alessandra" | Tim Young [Elevate Software] wrote:
> Are you using encrypted tables ? If so, then that is the reason for > the difference in performance. V4 uses strong crypto, while V3 does > not. yes, i'm aware of that, Tim. I've checked again tables and, well, two of them (secondary, but involved in processing) are actually encrypted. That can explain the 10-15% performance hit, i guess. I would like to do some more tests as soon as i've the time. > The repair procedure is more effective, and the indexes are pretty > much the same as with V3. ok fine, thanks! > << - with v3 i found that the "locate (.. [locaseinsentive])" > compared with "locate (.. [])" on the numeric field used as primary > index caused sometimes a serious performance hit when using "[]". Not > sure why this difference with a numeric field, but some processing > took a lot of time when the locate was with [] instead of > [locaseinsensitive]. Is this "bug" (or whatever you can call hit) has > been solved with v4 ? >> > No, case-sensitivity does not matter with V4 and integer fields. As > for V3, I would have to know which version you were using in order to > confirm whether it was a bug or not. 3.30 build 1.. the latest of v3. Unfortunately such weird results come out with some difficulties, since most of the operations (such like searches and updates) are done in real-time and only long-time processes can show performance problems. A couple of times, looking for the cause of these problems, we found that weird behaviour of [] vs. [locaseinsensitive]. Sandra |
Wed, Sep 23 2009 10:33 AM | Permanent Link |
"Raul" | Some of the reasons we upgraded to v4 (from v3 as well) for our products -
it might be of help to you : - proper encryption - stable (we had some custom changes made to v3 that we no longer need in v4) - v4 is still supported (if you pay annual maintenance) and new versions released regularly - support for latest Delphi (main benefit to you mainly) and latest Windows OS - triggers - larger string fields (we were able to get rid of some blobs) We've been happy with v4 - not running any kind of statistics calcs you mentioned so no performance issues like yours Raul "Alessandra" <alessandra@sarasoft.net> wrote in message news:FC6B8D84-16AF-42B7-B82E-EF4ED43755D2@news.elevatesoft.com... > Since i have some very pedantic customers, i guess i will have to justify > in some way the 10-15% of performance decrease in complex statistical > processes of our management softwares after the upgrade from v3 to v4. > That percentage has been observed by me after a lot of experiments, even > with bigger/smaller buffers etc. (our programs run locally or in LAN, with > archive-file sharing, no server, and the internal architecture is mainly > based on tables, not queries). 3.30 is definitely faster than v4. > What can i tell them? the indexes with v4 are more robust than v3? the > repair procedure is more effective than in v3? from their point of view, > obviously, they won't see anything else than a slowness, so i have to find > good excuses. Any suggestion? > > Sandra |
Thu, Sep 24 2009 6:44 AM | Permanent Link |
"Alessandra" | Alessandra wrote:
> yes, i'm aware of that, Tim. I've checked again tables and, well, two > of them (secondary, but involved in processing) are actually > encrypted. That can explain the 10-15% performance hit, i guess. I > would like to do some more tests as soon as i've the time. update & good news Removing encryption from every table involved in the processing, both from v3 and from v4 program versions, processing times are quite the same for v3 and v4. Small differences depends, in my opininon, on Windows buffers and cpu occupation, which can both vary depending on the status of the system, running applications, and user interactions with the system. Sandra |
Thu, Sep 24 2009 7:47 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Alessandra,
<< update & good news Removing encryption from every table involved in the processing, both from v3 and from v4 program versions, processing times are quite the same for v3 and v4. Small differences depends, in my opininon, on Windows buffers and cpu occupation, which can both vary depending on the status of the system, running applications, and user interactions with the system. >> That's good to hear. -- Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Friday, September 20, 2024 at 05:39 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |