And we were very impressed for all of them. Gigabase was used for a yellow pages cd, and Ismael from our team, added compression before it was added to the package.
With Perst we did some tests, and integrated it in our custom language (using ANTLR) very well. At the end we don’t used it comercially, but enjoyed its benefits (and we didn’t like to run a preprocessor!)

I think the quality of work from Konstantin deserves many prizes.

We agree with you. Our other database product, eXtremeDB, has been compiled in as little as 45K by one of the Taiwanese ODMs that manufacture mobile phone handsets under the Siemens and Philips brand names. And, eXtremeDB has no dependence on the C run-time library, allocates no dynamic memory, and does not require an operating system.

Bloat does cost and matter and we have focused on helping where we are able. Unfortunately, not everyone agrees with us.

I blame (but not exclusively) object oriented software architectures. Modern linkers don’t seem to prune libraries of unused methods (functions) any more. Why bother? It’s hard to tell at compile time if a virtual method might be used or not. And besides, most libraries are compiled as shared, so you can’t tell in principal. Without optimization you get pessimization.

It should be possible for the compiler to collapse the virtual method tree down to the code that is actually being used. Static linking could get rid of the dead wood. Except for libc, this would be much more efficient than shared libraries in memory footprint. Most shared libraries aren’t actually shared.

Software bloat costs. Eclipse takes several minutes to load under Windows XP with 2 GB RAM. That’s just to load. And yet, the 1987 Mac II with 2 MB RAM loaded Think C 5 in seconds. They do much the same thing, though, Think C was quicker on a machine 10,000 times slower with 1,000 time less RAM. I’m not suggesting we adopt slower, smaller machines. I’m suggesting we get more from the machines we have.

While there are some technical differences between the approaches that your group and my group took, both are addressing the same goal, and it’s great to see more energy in this area! Best of luck with everything!

Just to clarify, while Perst is now “McObject software” (and has been for several years), we’ve never sought to mask its origins. Our first news release on Perst was headlined, ‘From Russia, With Persistence…’; Perst’s Wikipedia page names Konstantin as Perst’s inventor. In addition, Konstantin (quite publically) authors and co-authors articles on Perst and on other McObject technology (See, for example, “Porting a Java ME midlet Between Blackberry and Nokia S40 and S60 devices”, on the Perst Lite DBMS for Java ME, http://www.embedded.com/products/softwaretools/202400727?_requestid=390746; also “Developing an object-oriented database system for J2ME-based embedded devices” at http://www.embedded.com/columns/technicalinsights/196602870?_requestid=391636).

Konstantin has also presented on McObject’s behalf at Embedded World in Europe and at JavaOne in the U.S. You’ll be hearing/seeing more from Konstantin. Look for an article on database indexes in the July issue of DDJ, with examples drawn from eXtremeDB. You’ll also see new and improved Perst docs and Web content — the new Tutorial and Introduction that you praised is just a start. Stay tuned.