Very interessting what you found and
thats draws a total different picture ...
to our environment :-(
1) FB1.0 classic instead of FB15 superserver
2) embedded SQL in plain C programmes mainly for data replication
3) using JDBC in the Webojb.Application
4) Isql (did not show for a big difference in my cases) although we use
" LIKE %XXXX% " clauses, too.


SO, our goal was to build and run a WEB-applcation and a replication
solution under MAC OS X with FB(1) and we did :-)

As soon I have a chance/time I will do a test of my cases for comparing
WindowsXP- MAC OSX
But I don't have a chance to compile my C programmes under Windows yet...
- maybe somebody gives a hint which compiler gcc ? runs under Win/
Command line...

yours
Claus

phil_hhn wrote:

>--- 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
>
>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>
>

[Non-text portions of this message have been removed]