Advantages of DOA over BDE
- Thread starter dtumbov
- Start date
Jonas Malmsten
Member²
For one thing, you don't need to install and configure BDE when using DOA, and the performance using DOA is lots better than using BDE, for me it is not an option going back to BDE.
dtumbov
Member²
Maybe I was not clear enough. I'm also using DOA, and it's not a question for me whether to use or not to use DOA. I meant, are there any benchmark tests that would clear and non-ambigously prove that DOA is much faster than BDE ?
The point is that we need to proove this to our hesitated customer.
The point is that we need to proove this to our hesitated customer.
I did my own benchmarks to make sure they were relevant to what I was doing. Comparing a recent build of DOA to BDE 5.something, I found that ...
- Connections were established about 0.25s faster with DOA. (Down from 250ms to about 10ms.)
- The overhead of calling a stored procedure dropped by about 0.5s compared to BDE. Since I have very tight response windows and multiple stored proc invocations per transaction this was very compelling.
- There was a smaller gain involved in executing SQL directly, but I didn't retain that record because I barely use direct SQL statements in my product.
G
- Connections were established about 0.25s faster with DOA. (Down from 250ms to about 10ms.)
- The overhead of calling a stored procedure dropped by about 0.5s compared to BDE. Since I have very tight response windows and multiple stored proc invocations per transaction this was very compelling.
- There was a smaller gain involved in executing SQL directly, but I didn't retain that record because I barely use direct SQL statements in my product.
G
Hi,
there is also another advantage for DOA.
The load on the server is much lower then with BDE. for example if you have two DBgrids displayed as master/detail relation and scroll in the master table i did some tests. Every time i scrolled in the same amount of data.
All numbers show values before and after the test.
1. number of open cursors cumulative (opened and closed by the session:
BDE: Start 24 End 403
DOA: Start 22 End 22 !!!!!!
2. number of parses
BDE: Start 28 End 784
DOA: Start 20 End 20 !!!!!!
3. Executes
BDE: Start 21 End 401
DOA: Start 20 End 396
On calls for stored procs you have a simmilar behavior but the gains are not so big.
Lars
there is also another advantage for DOA.
The load on the server is much lower then with BDE. for example if you have two DBgrids displayed as master/detail relation and scroll in the master table i did some tests. Every time i scrolled in the same amount of data.
All numbers show values before and after the test.
1. number of open cursors cumulative (opened and closed by the session:
BDE: Start 24 End 403
DOA: Start 22 End 22 !!!!!!
2. number of parses
BDE: Start 28 End 784
DOA: Start 20 End 20 !!!!!!
3. Executes
BDE: Start 21 End 401
DOA: Start 20 End 396
On calls for stored procs you have a simmilar behavior but the gains are not so big.
Lars
Hi,
what did you try to make the test ?
Did you use a TOracleQuery or a TOracleDataset ??
With an TOracleDataset you should look at "QueryAllRecords" property. If it is set to true you have a different behavior then with BDE. So if you realy want to see the pure DOA speed you should try something like this:
( Here comes only a code principle )
SQL Statement: "select sysdate from dual"
TOracleQuery *Query;
Query=new TOracleQuery()
SetQueryData()
Timerstart()
For(int i=0;iExecute();
TimerEnd();
If you try this with TOracleQuery and TQuery
you should nearly see the pure interface performance.
Hope this helps,
Lars
what did you try to make the test ?
Did you use a TOracleQuery or a TOracleDataset ??
With an TOracleDataset you should look at "QueryAllRecords" property. If it is set to true you have a different behavior then with BDE. So if you realy want to see the pure DOA speed you should try something like this:
( Here comes only a code principle )
SQL Statement: "select sysdate from dual"
TOracleQuery *Query;
Query=new TOracleQuery()
SetQueryData()
Timerstart()
For(int i=0;iExecute();
TimerEnd();
If you try this with TOracleQuery and TQuery
you should nearly see the pure interface performance.
Hope this helps,
Lars
dtumbov
Member²
Hi Lars,
Thanks for your reply.
I used TOracleDataSet, and "QueryAllRecords" was set to true. I changed it to "false" and then I tested with both, TOracleDataSet and TOracleQuery. The results were nearly the same. Comparing to BDE, i.e. TQuery, it was slight faster:
- 14,9sec with DOA
- 15,6sec with BDE (TQuery)
Number of loops were 100.
The query that I execute is select 30 columns from a view (constructed from 7-8 tables), with "where" clause of data field (index) and in "order by" clause 5 columns.
I find this very strange.
Thanks for your reply.
I used TOracleDataSet, and "QueryAllRecords" was set to true. I changed it to "false" and then I tested with both, TOracleDataSet and TOracleQuery. The results were nearly the same. Comparing to BDE, i.e. TQuery, it was slight faster:
- 14,9sec with DOA
- 15,6sec with BDE (TQuery)
Number of loops were 100.
The query that I execute is select 30 columns from a view (constructed from 7-8 tables), with "where" clause of data field (index) and in "order by" clause 5 columns.
I find this very strange.
Not every benchmark will show a significant performance difference. For a query with 7-8 tables and an order by clause, it may well be that 90% of the benchmark execution time is spent on the Database Server. Both the BDE and DOA will send this query to the server, so there is very little room for performance differentiation.
In general, DOA should be faster than the BDE. Sometimes a little bit, sometimes a lot. Furthermore DOA offers you many possibilities to optimize your application (Array DML, PL/SQL Tables, PL/SQL Blocks, Array Fetching, Oracle Monitor), and offers you more control over what is actually executed on the Oracle Server.
------------------
Marco Kalter
Allround Automations
In general, DOA should be faster than the BDE. Sometimes a little bit, sometimes a lot. Furthermore DOA offers you many possibilities to optimize your application (Array DML, PL/SQL Tables, PL/SQL Blocks, Array Fetching, Oracle Monitor), and offers you more control over what is actually executed on the Oracle Server.
------------------
Marco Kalter
Allround Automations
