Re: NewEra is heavy!
>>In article <46ph8s$fmm@raffles.technet.sg>, >>Daniel Qiao Jianxin <daniel@santeh.com.sg> wrote: >>Yes . NewEra is heavy for 486! >>I have tested a completed NewEra appplication, It's >>slow with my computer 486DX66/16MB RAM. After I transfer >>to Pentium 90Mhz/16MB RAM , It's speed met my expectation >>and performance is better. >Kerry Sainsbury, kerry@kcbbs.gen.nz wrote: >As part of my never-ending NewEra/Delphi comparison I decided to see how >memory usage compared when connected to large tables (people had suggested >that Delphi would not scale well). >The NewEra program was built with a SuperTable and the standard Query/Retrieve/ >Next/Previous buttons. Delphi's was via a TQuery object connected to a >TDBNavigator object capable of understanding Query-by-examples. Some people seems to avoide the SuperTables. Is that for this reason? > Delphi >Memory required to NewEra One Row All Rows >---------------------------------------------------------------- >Load program 2.4 meg 813k >Query 3873 rows 2.4 meg 25k 361k >Query 13621 rows 8.4 meg 25k 1.2 meg >Query 250000(ish) rows Crashes: Out of memory 25k 4.7 meg >Query 0 rows, after > the 13621 query 2.9 meg 0k >-------------------------------------------------------------- >The astonishing thing here is that NewEra loads the ENTIRE result-set >into memory, where-as Delphi loads the rows only as they're requested >(which is why there are two figures in the Delphi column, the first >figure is how much memory is used to display the first few rows and >the second figure shows how much is used when all rows have been >displayed). This astonishing thing is also how it works according to the manual. This is one of the many many reasons why NewEra should have supported VBX's from the outset, and now OCX's. There are database access tools available with a significant better performance (as to memory usage) and much more functionality than Informix SuperTables. (I belive there are even versions available that keep only a little more data than what is currently displayed in memory so even the memory increase seen in Delphi doesn't happen.) There are other problems with the SuperTables, so may be Informix should implement a new version. The above numbers realy shows they need to. This is less than useless! >The out-of-memory crash is on a machine with 24meg of real memory and >about 10 meg of Windows swap-space. >Interestingly changes to the data made with NewEra were not mirrored on >screen when the changed row is 'Previoused' back to - implying there is >a big SELECT * style SCROLL CURSOR lurking in there somewhere. This is very very bad Informix! Have you ever heard of dynasets? You could accomplish those with a key only cursor and individual fetches in the background. It is however very long overdue that you implement snapshots and dynasets at the database level as options when declaring cursors. This may not be availabel in the SQL-standard (although I seem to remember some talk about it in newer standards). These options are however more than simply useful. Applications can be made so much simpler, and avoiding the extra fetch to emulate a dynaset from the standard snaphsot cursors you now have, could increase performance significantly. >I am unclear how Delphi handles the scrolling of the cursor, there may >be some rowids floating in the background I wonder - might not be so good >on fragmented Informix 7 tables? Hopefully they use a scroll cursor. If not that may be available as an OCX. If it isn't some smart sole will sertainly soon make it available. This is the beauty of component based developement where you can buy these components at low cost. Another point: The C-code generator in NewEra seems to be related to the generator in 4GL. If you look at the 4GL generated C-code it is real low quality when it comes to optimization. This didn't matter much in 4GL. May be it does in NewEra. Generally: All this goes very strongly against what Informix has allways said about NewEra. They (including the top managers) has said that as NewEra compiles to C-code the run time requirements are lower than with alternative tools. You can therefore save a lot on cheaper machines than what is required for systems developed with these other tools. Are they lying, are these reports wrong (the developers may have done something wrong) or what is the real story? May be someone else with finished applications can tell us something. I realise the significant conflict of interest here (if you have a comersial application you don't want to tell to many people that it is slow or requires very powerfull hardware). Any information would be very interesting though. If these reports show the true picture of NewEra Informix has a significant problem, as do we. Maybe they should have bought Borland anyway. Their basic technology (compilers, user interfaces++) are clearly very much better than what Informix has been able to make. All Delphi lacks as compared to NewEra is application partitioning. A Borland Pascal compiler shouldn't be to difficult to implement under Unix, and the partitioning would be solved. Also remember Borland will have application partitioning on NT servers soon at least through support of OLE. VisualBasic 4.0 allready have this. NB! It is still a question how well this works. If it doesn't work well now in its first implementation there is however little doubt that it will in a later realase. Windows NT as a server is also gaining in both popularity, support and performance. The only reason why we are still interested in NewEra is application partitioning. We realy need that. However Informix has annonced *no* plans whatsoever to support neither SCO Unix (which we currently use) nor Windows NT (which we plan to use). Not any we have heard of at least. Does the king have any clothes? Seriously! Nils.Myklebust@ccmail.telemax.no NM-data, Dalsbergstien 7, N-0170 Oslo, Norway My opinions are those of my company