On Mon, 12 Oct 2009, Angel Pais wrote: > You're failing the comparison point. > Meassuring apples against bananas. > We cannot compare gui applications against console apps.
I do not compare user interface at all. I compare only simple IO operations in SEEK or SKIP which are the same in GUI and CUI application. The same reports created by application under WINE control are over 10 times slower. > Console ones are faster even on windows. I haven't tried to measure it. It's unimportant in current days. We have such fast computers that if sth is done in 1/100 sec. or 1/10 sec then for users it does not creates any differences. But if report is created in 1 hour by native code and then in 10 hours by the same code executed by WINE then it sth what blocks using WINE in bigger installations. None of my clients can accept it. And of course I'm talking about local file access. In remote access using file server the difference is much bigger then 100 times. > Unless you are developpping a web server, i/o access is a minimal part of > all your app running time. The time is important only in long operations. In the rest is not important at all. At least is not visible for users. In current days it doesn't matter it's CUI or GUI application. In both cases the code is executed fast enough to work interactively without any problems. User can see the slowness only when he tries to collect some data from tables and such operations needs some deeper analyzes. And here the speed overhead in WINE is the biggest one. If you execute pure .prg code, i.e. simple FOR/NEXT loop then code in WINE works with the same speed as native applications. Just execute speedtst.prg compiled as native application and as windows application. It's even possible that the windows one will be a little bit faster. But if you try to read or write from/to files or sockets then you will find that code executed by WINE is very slow. > Even considering that, most apps are running over a network and performance > is even worst and people are used to it. > Until Harbour has a working GUI development API, denigrating WINE is a > no-no, as for now, is the only usable platform on the linux world for real > apps. > If you want to achieve optimus performance then you have to make real 2 or > 3 tier apps. Tier 1:being a gui app client under wine or anything else. > Tier 2: a console app server under pure linux and an opcional 3rd. Tiers > with a rdbms if you don't like dbfs. I can understand that using RDBMS when tables are access remotely can increase the performance but it still will be many times slower then local access by remotely executed applications. User interface is less important here. You can divide your applications into two parts and execute native GUI code on client side which will communicate with application on server side which process data locally. Creating simple RPC protocol is not very complicated job. We have all things necessary to implement it inside HBRTL. It's enough to collect them together. RDBMS does not exclude using DBFs as storage format. ADS is RDBMS and can use DBFs. I've never understood why Clipper users used to think that SQL == RDBMS and DBFs != SQL or DBFs != RDBMS. These are three different things which can be used in one product or in separate products. It's quite easy to add SQL support to DBF tables but it will not convert the program to RDBMS. Just like RDBMS can use DBF format to store data because unlike common opinion said it's one of the most efficient data base formats in many situations. > The serious candidate for this is uhttpd but the are missing a protocol for > serialize-transmit-deserialize data in a 2 way relationship. I rather suggest to write simple RPC server from scratch. Using HTTP protocol and some universal HTTP server is not very good idea. At least it will be very inefficient in some cases and you will have to deal with many of problems caused by sateless protocol like HTTP. > Just my humble oppinion about our technological status. > Let's work all together to improve this marvelous plattform instead. > My hat off for this great meeting of great programmers Harbour has earned. In some spare time I'll write simple RPC server for Harbour. Maybe you and other users find it interesting. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
