--- In firebird-support@yahoogroups.com, Claus Heeg <heeg.c@t...>
wrote:

> Hi John
> Hi all !
> as a user of all FB plattforms AND MAC also - I found no

significant

> difference regds FB1.0.3 version - only the path on the MAC
> /libary/framework/firebird.framework....etc current..../bin
> is a nightmare to hack when no path is set ....
>
> the MAC version is stable and fast ... some where even faster at the

MAC

> compoared to Windows!
> I wd like to play with a FB1.5.2 port f MAC OSX 10
>
> yours
> Claus

Here are some more accurate performance figures I've taken today.
Similar to what was described earlier, the original query is:
"select * from TableA a join CrossRef x on x.pkA = a.pkA join TableB b
on b.pkB = x.pkB where b.keyword like 'magic%'".
We were interested in (a) just selecting 'magic' words or (b) just the
joins (without the where clause) to see if we could further identify
any bottlenecks.
These tests were performed from a Java program on a winXP box, and the
times given are the total for performing the query AND retrieving all
resulting rows.
Note:
i) The win2000 PC I tested against is the same spec as the winXP PC.
ii) All machines are running 1.5.1 super-server except for the eMac
which is running 1.5.0 classic.

WinXP Win2000 G4 iMac eMac (G4)
(1) Selecting words
"LIKE 'magic%'", or
"STARTS WITH 'magic'" 16ms 47ms 16ms 250ms
(returns 7 rows)

(2) Selecting words
"CONTAINING 'magic'" 47ms 62ms 265ms 235ms
(returns 20 rows)

(3) Performing joins
only 1.06sec 1.23sec 7.9sec 10.3sec
(returns 35,179 rows)

Points of note:
(A) The difference in performance between winXP and win2000 is
probably due to network factors (since the XP database is local and
2000 isn't).
(B) The difference in speed between the iMac and the eMac may be due
to the eMac running Classic server. The eMac should probably be
ignored in these tests.
(C) There is a huge drop in performance on the iMac in test (2), i.e
when doing a CONTAINING search. It occurred to me that since the
CONTAINING is case-insensitive, it must be doing a case conversion
internally when looking up the values. So I tested this by trying "...
where UPPER(b.keyword) STARTS WITH 'magic%'", and sure enough the
timing figures on ALL platforms matched the figures I took when doing
a CONTAINING search.
(D) Retrieving a large number of rows (the query includes joins) is
much slower on the MAC; I was wrong about this before. Could this be
an indicator that the MAC is resource-bound?


In Conclusion:
It seems the case-conversion on the MAC is very expensive. I ran a
simple test conversion in java of 10000 then 100000 Strings, and the
MAC was no slower, so it seems the OS itself doesn't have a problem.
So it would seem this could be a problem in the Firebird server when
running on the MAC.
Retrieving 35,000 rows should not be a major factor, but slows down
the MAC considerably - could it be resource-bound?

Ideas?
Thanks