View Full Version : seconds(), string length,...

2012-11-30, 02:53
I've tried to compare the performance of loops, expressions, conditions with several examples in a prg in VFP and got reference values with seconds(), see prg (uploaded as txt)

prg is not the same in lianja, because
a) seconds() in lianja doesn't return miliseconds like vfp9. So the result is 0,1,2,...
b) in a for/next-loop with i=1 to 100000, c=c+TRANSFORM(i) generates an error, because the string is too long

Are there any settings,... to handle these really basic activities like in vfp9?
Are there any other differences in "existing" functions,... but with different return values or restrictions?


2012-11-30, 03:22
As stated on many occasions in the forums character strings in Lianja are limited to 64k. Otoh most character functions can work on memos as well.

i don't see where comparing performance in for loops has anything to do with overall multiuser performance of a database app which is what the Lianja database engine has been optimized for. We have sites running 2000+ concurrent users with split second performance.

The Lianja database engine is also cluster aware and handles automatic server failover. It can be scaled up to as many users as you want by load balancing clustered app servers. The VFP compatible scripting language sits on top of this database engine.

You should also be aware of the shared program usage. Multiple users share the same complied code in memory as the code produced is both re-entrant and position independent. This provides for high scaleability particularly important in high traffic cloud apps.

Database tables can be up to 2^63 in size, and the indexes are fully balanced b+ trees.

There are functions in Lianja that go right down to millisecond granularity as are there functions for profiling both code and data I/O operations. You will find blog articles on the main website that cover this functionality.

There are also a number of commands for adjusting cache sizes and other such things to optimize and tune a particular app based on what it is doing e.g. index caching sizes, SMARTQUERY caching etc. there are blog articles covering these on the main website.

Not to mention speed of development.

2012-11-30, 04:05
I fully agree with your explanation

But, if we will "use Lianja for existing VFP-applications" we especially want to use the existing business logic. Therefore it would be much easier to have a list of restrictions, functions,... with differences to vfp9, because a migrated code without errors doesn't have to produce the same result. Either "everyone" is testing to find the differences or there would be a list of "different implementations".

That's what I wanted to say with: "Are there any other differences in "existing" functions,... but with different return values or restrictions?"

Maybe you can produce such a list of differences, so that everyone can check his code "after migration and before deep testing". Some differences can be changed in a smart way, because - as you mentioned - in Lianja there are much more possibilities than in vfp9.

We just have to know "what to change"

If there is such a list, excuse my thread

2012-11-30, 04:25
What we are planning to do is open up the documentation wiki so that we can all keep track of these things with workarounds or alternative ways of achieving the same thing. We will get this sorted out shortly.

If you find any differences we definitely want to know about them. Reason being, the vfp parser lets through a lot of undocumented things that developers sometimes think is the way it should work, not knowing that its actually syntacticly incorrect. The Lianja parser is stricter.

if you take a look at the roadmap Claus you will see that we do react to differences as they are reported and as a v1.0 product it's shaping up quite nicely.

We are not a fly by night company, and our goal is to grow this technology into something compelling that you can trust will be around for a long time.

Thanks for the feedback and the positive appreciation of what Lianja is all about. By getting involved as you are, it will just make the product better and better.

It's very encouraging for everybody involved to see downloads almost at 10,000 now, while we are in beta. When cloud and mobile are ready I foresee these numbers growing rapidly.

in these uncertain economic times there are are serious advantages in being cross platform, cross ui and cross database, and not being tied to any one operating system vendor.