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

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

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

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

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

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

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

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