>Hi Hank,
>
>>What VFP offers is the right level of abstraction. Lianja is the only app development and deployment platform I've seen that has that right level of abstraction for >me for web/mobile apps. There are things I want to be better in it. And they are getting better, in a steady fashion
>
>I ran a few tests on Lianja in its early days with a view to transfer a significant code base from VFP into it. This code base relies heavily on SQL tapping for temp VFP cursors (of course optimitized with indexes). In spite of its ISAM nature, the speed of the whole stuff is pretty decent.
>
>Lianja cursors were not up to that task - run time was always a heavy multiple of their fox counterparts, which would mean a full rewrite of the logic from the python interpreter. I stopped investigating at this stage. I understand that Lianja is targetting business-and-mobile-centric apps. And this use of VFP cursors is certainly not academic and a bit passé but still feel something was lacking at the core of their local engine at that time (windev, for example, has changed tremendously in this field). Has the stuff been improved?
>
>Daniel

Hi Daniel,

Much of VFP's speed with data comes from extensive caching, not from rushmore (Christof has published on this with data to back it up). Lianja has settable caching. That said, Lianja is made for app serving, where unlimited memory for hundreds of users would typically be impractical. So some redesign of queries is in order.

Lianja's index usage is very fast. Where I've encountered slowdowns in sql queries returning small numbers of records from tables with lots of row, adding the appropriate index helped a lot. EXPLAIN makes this easy to determine. VFP covers up a lot of that because of its use of caching. With VFP and sufficient memory, it's like having lookup tables in memory. Lianja does hold indexes in memory (that's one of the cache settings).

So I don't think it's as much the engine that's the issue, as much as it's a different perspective on what's important, which in turn leads to some differences in how data is used.

All that said, our customers demand that we use MSSQL. The issue there is the way PK's are used -- they have to be generated as non-clustered or else PK index scans will eat up CPU, which then clogs execution memory space, etc. My takeaway is that whatever backend we use demands accommodation of some sort.

Lianja's data engine speed has reportedly been improved in the every release of Liana, it seems, including the current release-to-be, 2.1. I haven't tested these improvements so I can't tell you how much they have changed things.

Hank