[V4RB] 1.x Open() Delay in Win32

[Russ Tyndall]

On 4/5/06 1:45 PM, "Ruslan Zasukhin" <sunshine at public.kherson.ua> wrote:

> On 4/5/06 8:00 PM, "Russ Tyndall" <fitzbew at nc.rr.com> wrote:
> 
>>>> The *first* time the database is opened on XP, the db.Open(folderitem)
>>>> function takes 10 seconds or so to return.
>>>> 
>>>> If I close the app, and re-launch the app, the Open() function takes only a
>>>> split-second.  All subsequent re-launches are blazing fast.
>>>> 
>>>> But once I reboot, the first db.Open() is slow again.  I get the same
>>>> behavior in WinMe and Win2000.
>>> 
>>> Sounds like you become faster because Virtual Memory cache db file into RAM.
>>> 
>> 
>> Well, the commit charge in Task Manager does not change after the call.
>> So...I'm skeptical.  But with humility.  Would you expect the Commit charge
>> to increase as said db is written into VM?  It must, I believe.
> 
> Russ,
> 
> Virtual Memory can save 100-200-300MB of application and its data in the
> RAM.
> 
> You cannot see this on Windows. On MacOS X it is shown as "inactive" RAM.
> 
> If next app start touch the same disk files then they are loaded from RAM.
> This is what I mean.
> 
>>>> I assume the delay is V4RB populating the cache, which is cleared at
>>>> reboot.
>>>> (The cache is persistent between application sessions?)
>>> 
>>> Right, cache. But not Valentina cache. System cache
>>> 
>> 
>> See above.

I did some more research on this (have to reboot to get back into "slow"
state), and also poked around on the 'Net to make sure I am interpreting the
Task Manager readings correctly.

In Win XP Home (SP2), 2.5ghz Celeron D with 512 mb of physical RAM, it takes
24 wall-clock seconds for V4RB 1.x to open a 155mb encrypted database the
*first* time after a startup/reboot of the PC.  Subsequent openings are very
speedy.

The amount of memory used on the PC increases by only 3mb during the Open()
call.  This is true during each Open(), not just the first. So, I do not
think the delay is due to the OS caching the database. (System cache and
Kernel memory hardly change at all.)

The first time the DB is opened, this 3mb of memory is consumed very slowly
during the 24 secs.  On subsequent openings, this 3mb is consumed quickly.

My (virtual) Win98se PC with 128mb of RAM does not hesitate at all during
Open().

Even more disappointing, Vstudio suffers this slowdown also when opening an
unencrypted converted version of the same 155mb database so I don't think
migrating to 2.x will help with this. It also rules out a Realbasic cause.
(Also, that would seem to rule out a problem relating to the encryption.)

The delay *does* appear to be related to db size.  I experimented with a
trimmed down version of the db (28mb), and it opened quickly every time.
Also interesting, the Open() call on this smaller db does not cause *any*
noticeable memory to be consumed.

I have another 388mb db that uses an alternative engine that opens swiftly
*every* time on the same machine.

I'm quite puzzled about what to do here, but I don't think any of us would
expect either 1.x or 2.x to take so long to simply open a 100-200mb db.

-- 
Russ Tyndall
Wake Forest, NC