developer toolbox » harbour

to harbour mailing list

For sure, there's a lot of interest for LETODB or similar RDD in harbour.

There is problem with project support, it seems Alexander is mainly unavailable.

It would be best to get feecback from author about this topic.

But, if he is unreachable, I don't see any obstacle (project license GPL v2) for including LETODB in harbour svn.

LETODB current users will get more confidence in the future of the project.
It will be quite enough to be close to eyes of Przemek and Victor :)

It would be benefit for other harbour users also: there is strong need for opensource client-server DBF RDD.

For sure, inclusion of LETODB can only have positive efetct on LETODB project itself.

How to do that if we cannot reach Alexander ? What are other's opinion ?

Regards,
Ernad

----- "Viktor Szakáts" <harbour.01@syenar.hu> wrote:

> Dunno where to address this, but I tried LetoDB the other
> day with production app, and instantly stumbled upon a
> fatal because dbExists() isn't implemented.
>
> I also had to patch source to fix hb_socket...() function
> collision.
>
> It'd be great if someone could fix these in LetoDB repository.
>
> BTW I have nothing against hosting LetoDB in Harbour
> repository, but here Alexander has the final word, so if
> he also likes the idea, plus other Harbour developers also
> agree, we can do it.
>
> Brgds,
> Viktor
>
> On 2009 Sep 24, at 18:15, alxokhotnikov wrote:
>
> > Hi
> >
> > NETIO
> >
> > locally (two processes)
> > adding 100000 entries - 80 seconds
> > Read all entries - 10 seconds
> > Update Records - 35 seconds
> >
> > the network (two computers)
> > adding 100000 records - 320 seconds
> > Read all entries - 60 seconds
> > Update Records - 420 seconds
> >
> > And all of this, any interruption of the client (eg, hanging) leads
> to
> > data corruption (index)
> >
> >
> > LetoDB
> >
> > locally (two processes)
> > adding 100000 entries - 10 seconds
> > Read all entries - 2 seconds
> > Update Records - 18 seconds
> >
> > the network (two computers)
> > adding 100000 entries - 45 seconds
> > Read all entries - 10 seconds
> > Update Records - 110 seconds
> >
> > 1. Data are not damaged
> > 2. The results even better than the RDDADS
> >
> > Maybe in the harbour add LetoDB (or take it as a basis)?
> >
> > 2009/9/24 Przemyslaw Czerpak <druzus@acn.waw.pl>:
> >> On Wed, 23 Sep 2009, Mindaugas Kavaliauskas wrote:
> >>> I want to share more test results after using memory FS in real  
> >>> project.
> >>> Report generation time (min:sec):
> >>>   Local disk database              3:07
> >>>   Network database                25:52
> >>>   Local disk database and MemFS    2:22 + 0:03 (copying to memory
>
> >>> FS)
> >>>   Network database and MemFS       2:24 + 0:13 (copying to memory
>
> >>> FS)
> >>
> >> Very nice contribution and also final results.
> >>
> >> In last week I've found a while to make some test with NETIO and
> MS-
> >> Windows.
> >> The test were done on WinXP, SMB and NETIO servers were on Suse  
> >> Linux, T100
> >> LAN. Any opportunistic locks in SMB server were disabled.
> >> The test program is attached below. I was testing only shared
> mode.
> >> I tested SMB, NETIO and also xHarbour REDBFCDX and there is not  
> >> noticeable
> >> results. All tests gave results similar:
> >>
> >> Harbour 2.0.0beta3 (Rev. 12431), Windows XP 5.1.2600 Dodatek  
> >> Service Pack 3
> >> RDD: DBFCDX type: CHARACTER (shared)
> >> records: 10000, repeated: 1, modulo: 10000
> >> creating database and index...        69.66 sec.
> >> skip test...                          17.38 sec. count: 10000
> >> revers skip test...                   17.28 sec. count: 10000
> >> testing seek...                       17.28 sec. count: 10000
> >> goto test...                          17.34 sec. count: 10000
> >> goto+skip test...                     30.38 sec. count: 10000
> >> skip test...                          17.41 sec. count: 10000
> >> revers skip test...                   17.27 sec. count: 10000
> >> testing seek...                       17.30 sec. count: 10000
> >> goto test...                          17.27 sec. count: 10000
> >> goto+skip test...                     30.31 sec. count: 10000
> >> Total execution time...              268.91 sec.
> >>
> >> and the difference were smaller then 0.5%. Just simply the net  
> >> overhead
> >> is such huge that rest is unimportant.
> >> The difference can be seen only in local tests and here Harbour
> was
> >> faster then xHarbour but it's mostly result for faster Harbour VM.
> >>
> >> The local disk tests in WinXP and Harbour using DBFCDX with native
> IO
> >> took ~2.50 seconds. It means that in above test Harbour consumes
> less
> >> then 1% and rest is the cost of network overhead.
> >>
> >> BTW testing REDBFCDX do not forget to add RE_TURBO( .f. ) -
> REDBFCDX
> >> enables dirty reading by default or add Sx_SetTurbo( .t. ) to
> other
> >> RDDs to enable it too. Otherwise there is no sense to make any  
> >> comparisons
> >> and probably it's also the reason why Miguel has better then native
>  
> >> SMB
> >> protocol results testing REDBFCDX.
> >> Of course the difference strongly depends on hardware transport  
> >> layer,
> >> the results in WAN or in T10/T1000/T10000 LANs can be completely  
> >> different
> >> but this test clearly shows that to reach real speed improvement
> it's
> >> necessary to create RDD oriented server which can group IO
> operations
> >> in some bigger logical units to reduce number of packages which  
> >> have to
> >> be send and confirmed. Operating only on transport layer like NETIO
>  
> >> we
> >> can reach some small improvement yet, i.e. we can disable  
> >> confirmation
> >> in UNLOCK operation what in above tests can increase the SKIP tests
>  
> >> ~20%
> >> (Maybe I'll add such extension soon) or we can try to group some  
> >> operations,
> >> i.e. join index lock and concurrent access counter read into
> single
> >> operation what may give even 50% speed improvement in the SKIP but
>
> >> it needs
> >> modifications in core RDD code so I do not like it because it may
>
> >> start
> >> very danger in longer terms process of adding local hacks to core
>
> >> RDD code.
> >>
> >> best regards,
> >> Przemek