[fpc-pascal] msedb and fcl-db benchmarks

Coco Pascal Coco.Pascal at xs4all.nl
Tue Jul 17 21:27:26 CEST 2007


Joost van der Sluis wrote:
> On Tue, 2007-07-17 at 19:58 +0200, Coco Pascal wrote:
>   
>> Joost van der Sluis wrote:
>>     
>>> Discussion: What tests could I do more? Is there something I overlooked?
>>>   
>>>       
>> To me it seems that benchmark tests on 100000 records are missing 
>> relevance more and more.
>>     
>
> Offcourse, but it has some usefull results.
>
>   
>> I'm interested in responsiveness in n-tier solutions: opening connection 
>> - begin transaction - quering/updating mostly 1 or a few records - 
>> commit transaction - close connection - browsing a small (<50) set of 
>> records .  Opening /closing connections could be skipped in this context 
>> when a connectionpool is used. 
>>     
>
> I did those tests quickly. There wasn't any difference between the two.
> But compared to time the open/close takes, you can't measure the browse
> speed if you use only 50 records. So to test the browse speed, I simply
> used more records. (Also not fool-proof, but that wasn't my intention)
>   
So this makes your case, doesn't it. Martin argued that his dataset was 
designed to work together with his visual controls.
Because it makes no sense to use large datasets with those controls, one 
could argue that performance can't be relevant in this case.
>   
>> Also I'm interested in tests selecting/updating/browsing sets larger 
>> than 1 million records, obviously local.
>>     
>
> That's simple, adapt the amount of records that is created, and then
> call the edit-field tests.
>
>   
>> Consequently one could ask if one type of dataset could satisfy 
>> requirements regarding performance and use of resources in both cases.
>>     
>
> I think you can. Unless you want to edit all 1 million records. (as I
> told in my last message)
>
> It becomes different if you only need to browse one way through the
> records. (or, obviously, you have a dataset with only one record as
> result)
>
> Or can you explain to me how you can make a dataset faster for usage
> with more records, and at the same time slow it down for low
> recordcounts? (or the other way around)
>
>   
I'm refering to very large buffered datasets held in memory by 
middleware for fast access. It is well known for instance that Delphi's 
TClientDataset chokes with say 100000 records, whereas different designs 
scale much better, TkbmMemTable for instance. Not long ago Marco van der 
Voort suggested (in another forum) to have a look at something like  his 
"lightcontainers", apparently someting completely different  (than for 
instance a TList based  dataset).
I've put forward this point  because  for datasets used with visual 
controls speeds can't  be the issue at all. But for very large sets it 
certainly is.




More information about the fpc-pascal mailing list