This is Steve Weick, CTO & VP Engineering at Encirq Corp., developers and IP owners of DeviceSQL. I would like to address D. Richard Hipp’s statements.
RDH:"If you view their web presentation and/or try out Encirq's products, I would be very interested to hear your impressions. Even better would be if you could blog about it.Encirq has for years been running Google Adsense ads claiming to be 20x faster than SQLite. (Dunno why they have now reduced that claim to 5x faster.) But I have never yet seen an independent confirmation of this. Nor even have I been able to find anybody who is actually using DeviceSQL in a product. Web searches turn up nothing but marketing literature coming directly or indirectly from Encirq. Some independent analysis (regardless of whether it is favorable or unfavorable to SQLite) would be appreciated." SW: The DeviceSQL performance advantage over SQLite has been demonstrated by running a series of benchmarks with a variety of operations using Linux on PCs, ARM, Freescale, and other processor platforms that are commonly used in embedded applications. In all our benchmarking we attempt to present SQLite capabilities at their best. So we "tweak" SQLite to use indexes, not scans, in all cases. We also opt (for fairness) to compare the products using only paged storage with B-trees like those of SQLite. In many cases our other indexing techniques are far superior to this approach. We provide detailed benchmark reports as well as the benchmark code to prospective customers. We have seen that SQLite performance, while poor on larger PCs, degrades significantly on small processors compared with DeviceSQL. We believe that this is due to the fact that SQLite uses a number of techniques that consume large amounts of the available CPU capacity, and it is therefore unable to operate at the flash or disk speed. While SQLite performance has improved in some areas in the last few releases, we can still show that DeviceSQL is 2-10X faster in all of the interesting cases and 50X faster in one odd case. You do not see client listings on our site because our clients believe that DeviceSQL is part of their competitive advantage and they do not like to advertise to their competition what they are using. You will however see outspoken users of DeviceSQL explain why they chose DeviceSQL over SQLite, if they were not able to make SQLite satisfy their requirements, like Gemstar-TV Guide. RDH: "My understanding of DeviceSQL is: * It is NOT transactional. There is no such thing as ROLLBACK." SW: This is false. DeviceSQL DOES support transactions and ROLLBACK, just not in the traditional, resource intensive manner of maintaining a journaling log. Rather, we use a simple approach which maintains data integrity, high performance, and small footprint without introducing the possibility of corrupting the journal. RDH:"* If you lose power during a write, your database is toast." SW: Again, not true. DeviceSQL has supported transactions and rollback since its very first release in 2003 and continues to do so today. Contrary to Mr. Hipp's assertions, DeviceSQL ensures that writes complete successfully (ensuring no power outage can cause corruption) before continuing after a commit. In fact, because of DeviceSQL's novel (and very simple) commit approach, it is possible to prove that application data is recoverable (this is quite difficult to do with the logging approach used by SQLite and important for devices that must handle critically important data). In addition to fast updates, the DeviceSQL approach yields substantially shorter boot times after failures. This is often important to consumer devices where the end user will not tolerate long boot times. RDH:"* If your database schema changes, you have to recompile your application." SW: This is true. DeviceSQL is targeted for embedded applications where executables change rarely, so schema changes are a big deal, and the clients do not want to make changes to the schema after production begins. We do however, offer migration utilities and approaches for doing this if needed. RDH:"* The database file format changes depending on the schema." SW: Not sure what this statement is about, although all databases have this to some extent. RDH:"* DeviceSQL is not a general-purpose database engine. You compile SQL statements into C code on a development workstation, then compile the C code for your embedded device." SW: Neither is SQLite by this standard. Both products are application-resident database engines that live in the application's address space. The question is whether the main use model is compiled SQL versus interpreted SQL or C APIs. DeviceSQL also supports C query interfaces. This is rarely an issue in small devices where the database manager is embedded in the application, and where our compiled language can be used to implement application database logic. RDH:"I can imagine circumstances where the DeviceSQL approach, while much less flexible and forgiving than SQLite, might be a better way to go, depending on what you are trying to do. But I have not gotten good vibes from Encirq as a company. And I have no idea how reliable the DeviceSQL product is. I would really appreciate your thoughts on that subject." SW: Your opinion about DeviceSQL does not match what our clients say about DeviceSQL. Our product is commercial grade, developed and supported by an engineering Team with 100+ years of combined DBMS development expertise. DeviceSQL is highly reliable and has an outstanding record of QA with millions of units shipped to date. We have never been designed out of a customer product. SW: Richard, We have written to you directly before to ask you to stop the FUD and incorrect statements, and you have chosen to continue. I suggest you not waste everyone's time by circulating deliberately misleading information. Steve Weick -- View this message in context: http://www.nabble.com/Improving-performance-of-SQLite.-Anyone-heard-of-DeviceSQL--tp14280006p14310445.html Sent from the SQLite mailing list archive at Nabble.com. ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
