>>> >>> I can only admit I share your feelings here. >>> Pity the ODBC backend hasn't found much love so far. >>> >> If there are many internal issues with the ODBC implementation you might > want to look at DTL (database template library) >> as either a good source of inspiration or an alternative to SOCI. >> DTL works only using ODBC so they have spent a lot of time ironing out the > bugs. >> >> I also found it was a little faster than SOCI for my main Oracle test case. > > Hi Bruce, > > Could you give overview of your use case? > What was the difference, roughly? > > Perhaps we could add some performance/timing cases to the tests. > > Best regards, > -- > Mateusz Loskot, http://mateusz.loskot.net > There was not much in it performance wise but returning to my results I see SOCI has a slight edge over DTL if optimised. It is just slower by default. I went for DTL primarily because it is an object relational mapper. I would like to run the same queries on different kinds of database (for example for testing) without having to change the code. I can't remember if that's possible in SOCI but it is in in DTL by using ODBC.
The following are taken from a document I wrote when evaluating different options but with the details removed. One option I didn't get to try yet is hibernate. It is claimed to be efficient but I suspect it won't match up to SOCI or DTL. I think it is a claim like ODBC being slow (or Oracle being a good choice :) ) that is not fully supported by the evidence. Regards, Bruce. Test Query The query produces 2.8 million rows. The query combines results from two tables in what is termed an equi-join (a inner join which joins rows that have equal values for columns of interest). Results The difference between the naive query and the standard query is that in one case I just coded what work (i.e. out of the box performance) whereas subsequently I read the documentation for each product on how to optimise performance. Database Access Mechanism Connection Type Execution Time Naive Query Standard Query Comments SOCI Oracle (OCI) real 586.36 user 68.76 sys 56.17 real 30.11 user 11.69 sys 1.95 Bulk fetch operations are not used by default. The recommended idiom performs very well. Performance can be tuned by increasing the number of rows processed at a time. This result is retrieving 1000 rows at a time. DTL ODBC real 97.58 user 74.55 sys 5.12 real 32.98 user 15.84 sys 1.24 Bulk fetch operations are used by default. The performance is improved by changing the class definition to reflect the column types more accurately. E.g. using tcstring<7> for VARCHAR2[7] rather than int. CppDB OCI real 91.00 user 69.49 sys 4.34 JDBC JDBC real 238.11 user 57.23 sys 60.21 real 160.06 user 26.77 sys 12.80 The performance of the naive implementation was poor because system.out was used instead of OutputBuffer. It thus reflects naivety with use of Java rather than JDBC. SQLPlus real 178.07 user 52.02 sys 35.62 SQLPlus would seem to be far from optimised. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Soci-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/soci-users
