Performance / limit of the addressbook

[wos]

Can it hold about 600 companies with 20 fields each record?

[Zhang Weiwu (zhangweiwu)]

Test case with 100 records of 16 fielsd:

VIRT = 22140
RES = 9860

 2311 almustaf 20 0 22140 9860 5800 S 0.0 1.3 0:00.63 wish8.5

Test case with 900 records of 16 fields.

VIRT = 24248
RES = 11m

Top shows:
 2159 almustaf 20 0 24248 11m 5768 S 0.0 1.6 0:01.59 wish8.5

Test case with 10000 records of 16 fields:

VIRT = 24532
RES = 12m

 2357 almustaf 20 0 24532 12m 5764 S 0.0 1.6 0:01.65 wish8.5
----------------

In comparison with firefox:

 2195 almustaf 20 0 512m 116m 36m S 10.6 15.5 0:35.31 firefox-bin

[Zhang Weiwu (zhangweiwu)]

Wait, all above result are tested on Linux, Ubuntu 10.10. It shows holding 10000 records is no problem, in fact pretty far from overloaded for modern computers. I know we talked about a limit of 700 records, it could be either a Mac OS limit or due to AustCham used a customized theme (instead of the default theme which we use for samples that we sent to GCD).

I will test Mac OS X case and report here.

[Zhang Weiwu (zhangweiwu)]

The new test data on Mac OS 10.05

Case: 100 records
  PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE
  154 tclkit-dar 0.0% 0:01.31 2 66 117 4612K 19M 12M 205M

Before:
  PhysMem: 84M wired, 180M active, 16M inactive, 287M used, 481M free.
After
  PhysMem: 86M wired, 189M active, 16M inactive, 298M used, 470M free.

Case: 900 records
  PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE
  160 tclkit-dar 0.0% 0:02.59 2 67 119 6756K 19M 14M 206M
Before:
  PhysMem: 85M wired, 180M active, 22M inactive, 293M used, 475M free.
After:
  PhysMem: 87M wired, 192M active, 25M inactive, 311M used, 457M free.

Case: 10000 records
  PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE
  179 tclkit-dar 0.0% 0:02.70 2 66 119 7024K 19M 15M 206M
Before:
  PhysMem: 82M wired, 159M active, 36M inactive, 284M used, 484M free.
After:
  PhysMem: 84M wired, 169M active, 36M inactive, 296M used, 472M free.

[Zhang Weiwu (zhangweiwu)]

Both test data from Linux and from Mac OS X seems to show under a modern computer configuration the software can handle 10,000 records with ease. If we do stress test it might be able to handle ten times or a hundred times more records, making it usable at million records level.

This is a sharp difference from the case we had half a year ago.

The test I am doing today is different from half a year ago, major differences are:

- We use a built-in theme. Half a year ago we tested data of AustCham which used a 3rd party theme.
- Many bugs are fixed during the half years, although non towards performance.
- AustCham data have clearly much more characters per field than our test data.

So the high performance we receive now can be related to any of these differences.

[Zhang Weiwu (zhangweiwu)]

I had to correct the previous performance at 10000 records on Mac OS X is a type, actually is 1000 records.

[Zhang Weiwu (zhangweiwu)]

Here is test result on Mac OS X 10.5 with AustCham's 3rd party theme:

Before:
  PhysMem: 89M wired, 277M active, 60M inactive, 432M used, 336M free.
After:
  PhysMem: 92M wired, 293M active, 60M inactive, 452M used, 316M free.
Top:
  PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE
  220 tclkit-dar 0.0% 0:04.10 2 66 136 8748K 20M 18M 154M

So it seems the theme did not put much stress on it.

The doubt then goes to the records. The way to find it out is to use a real complicated records, for example taking output from GCD and write a small program to convert it to addressbook-DVD, and check that one.

[Zhang Weiwu (zhangweiwu)]

I put this bug Invalid as a way to close it, because there is no other option to close this issue without marking it released (which i should not do).

In short, answer is positive, the program must be able to handle the stress 600 companies with 20 fields each record. Even though I plan to do further testing with GCD data, the testing is more for a scientific interest than a practical need.