We recently noticed that INSERT and UPDATE queries with ForceBufferFlush = TRUE on Vista
are more then 10 times slower then same queries on XP.

Basically what we see is

Windows XP, ForceBufferFlush = false, FAST
Windows XP, ForceBufferFlush = true, FAST

Windows Vista, ForceBufferFlush = false, FAST
Windows Vista, ForceBufferFlush = true, SLOW (more then 10x times slower then any other mode)

Is that expected? Are there any known workarounds?

It does not matter where we create our database. We tried in the AppData\ and in the
Public\Documents - results stay the same.

We tried on 3 different Vista Business boxes - results stay the same.

Any ideas?

timjones


I'm interested - can you post your test app to the binaries?

Roy Lambert

Hello To,.

> Windows XP, ForceBufferFlush = false, FAST Windows XP,
> ForceBufferFlush = true, FAST
>
> Windows Vista, ForceBufferFlush = false, FAST Windows Vista,
> ForceBufferFlush = true, SLOW (more then 10x times slower then any
> other mode)
>
> Is that expected? Are there any known workarounds?

Have you test it with Vista SP1 ?

--
Charalabos Michael - [Creation Power] - http://www.creationpower.gr

"Charalabos Michael" <chmichael@_-_no_-_creationpower_-_spam_-_.com> wrote
in message news:948CB9AF-FAA8-4CFB-8115-AAF4D69C929C@news.elevatesoft.com...
>
> Have you test it with Vista SP1 ?
>
Even thats been withdrawn.
Rita

Hello Rita,

> "Charalabos Michael" <chmichael@_-_no_-_creationpower_-_spam_-_.com> wrote
> in message news:948CB9AF-FAA8-4CFB-8115-AAF4D69C929C@news.elevatesoft.com...
>> Have you test it with Vista SP1 ?
>>
> Even thats been withdrawn.
> Rita

Knock, knock, knocking my head on doors .... yeah yeah yeah ...

--
Charalabos Michael - [Creation Power] - http://www.creationpower.gr

Hi Tim,
>Are there any known workarounds?
I haven't tried leaving ForceBufferFlush to true but I can imagine there
would be some performance hit. Although I can't explain why its 10X as much
on Vista.

Why don't you leave it as False on the session and use the table's
"FlushBuffers" method at key areas when required only. I typically
FlushBuffers after important post or when closing forms. This technique and
it seems to work well. I have several apps deployed on Vista machines
without any problems.

Regards
Gregory Sebastian

Alex,

<< Is that expected? Are there any known workarounds? >>

I wasn't aware of any issues like this, but it doesn't surprise me.  I'll
have to do some investigating here with my Vista test machine and see what I
can come up with.  I'll post any information I find here.

--
Tim Young
Elevate Software
www.elevatesoft.com

>> but it doesn't surprise me.

Tim, can you explain why you are not surprised?

Whatever low level call is in DBISAM is an old call (back to NT4 of such, right?).

Please let us know what you find. Our app really suffers on vista right now.

We need FlushBuffers to keep our db stable (so when the PC loses power, or such the DB is
usually not damaged).

> We need FlushBuffers to keep our db stable (so when the PC loses power, or
> such the DB is
> usually not damaged).
This is exactly the reason why I use flush buffers too. However I set
ForceFlushBuffers to false in the session component and I control when to
FlushBuffers myself by simply calling the tables FlushBuffers method
strategically.

For example if you programmatically iterate and edit each record in a large
table while ForceFlushBuffers is true, you will get very poor performance
whether its XP or Vista. If you set Session.ForceFlushBuffer = False and
just call the tables FlushBuffers method after iterating and posting the
last record in the table you will still get V good performance with minimal
exposure to power outage etc.

Regards
Gregory Sebastian

Sam,

<< Tim, can you explain why you are not surprised? >>

Because Vista is a dog and has all sorts of new problems with things that
previously worked okay, such as the SMB protocol.

<< Whatever low level call is in DBISAM is an old call (back to NT4 of such,
right?). >>

The FlushFileBuffers API call has not changed in Vista, so it has nothing to
do with which call we're using.

--
Tim Young
Elevate Software
www.elevatesoft.com