Any updates as to why this is sooooo slow on vista?

It is forcing us to do some hacks that we would prefer to avoid...

Sam,

<< Any updates as to why this is sooooo slow on vista? >>

I won't be able to look into this until later in the week, and frankly I
don't think I'll be able to do anything other than confirm or not confirm
the behavior.  If it's an issue with Vista, then it's an issue with Vista,
and you'll have to wait until MS releases a fix for it.

--
Tim Young
Elevate Software
www.elevatesoft.com

It would be helpful to know that you see problem too and we need to know which Win32 API
call takes so long. Then we have something to blame on Vista and Microsoft. This is not
the case right now. What we see at the moment is "DBISAM works slower on Vista".

--------
"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:

Sam,

<< Any updates as to why this is sooooo slow on vista? >>

I won't be able to look into this until later in the week, and frankly I
don't think I'll be able to do anything other than confirm or not confirm
the behavior.  If it's an issue with Vista, then it's an issue with Vista,
and you'll have to wait until MS releases a fix for it.

--
Tim Young
Elevate Software
www.elevatesoft.com

<< It would be helpful to know that you see problem too and we need to know
which Win32 API call takes so long. Then we have something to blame on Vista
and Microsoft. This is not the case right now. What we see at the moment is
"DBISAM works slower on Vista".  >>

The API call is FlushFileBuffers.   Frankly, I'm not quite sure what you
want me to do regarding this issue in the event that I confirm that it is
the case.  If you take an application that works just fine on XP and then
put it on Vista and it runs really slow, then most likely the issue is
Vista.  It doesn't take too much thinking to come to this conclusion.

Are you thinking that DBISAM is doing something specifically wrong that it
causing it to slow down ?  I can assure you that this is most definitely not
the case.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

We are all techies here, and we all know that Vista is the problem.

That said, we also need to thoroughly understand what is going on, and to clearly see exactly what the problem is. (Exactly means: win32 api call X when used in DBISAM, performs Z times slower on vista, or such).

From my desk, I can see that a given piece of code is running not 10x slower, but 20-80x slower on vista. It is unusable slow. It makes our software, which flies on XP, simply unusable on vista.

And this code is DBISAM.

So here is where I need your help. I apologize, but I lack the time to dig through DBISAM. I am really sorry I cannot deliver this on a silver platter. (I would like to!)

We need, from Elevate, a look at this issue. We need to know:

a) What the Win32 call is that kills DBISAM

b) Is there a simple workaround we can use in DBISAM that preserves our overall approach?
     (perhaps it is a message pumping problem, or ???)

c) Once the problem is understood, perhaps there will be an adjustment to DBISAM itself to work around the issue.


I hope we can all appreciate that we can't just take a hammer out. The approach we use with DBISAM (of flushing buffers, etc) we arrived at after much shed blood (trashed data, etc etc). We cannot just 'undo' our approach. The approach
we use is a DBISAM supported approach, and has been thoroughly tested by us, and has proven itself in the field.

But there is a problem on vista. A HUGE problem.

Please lend a hand as soon as is feasible.

Thank you so so much!

Hi Sam,

Have you tried this with Vista SP1?

When Vista first came out I tried it and found it to be unusable as it
was just to slow.

I have recently tried it again with the SP1 (Beta) installed and I have
been working for over a month now with no problems.
(I also turned the UAC off)

Chris Holland

Sam wrote:
> Tim,
>
> We are all techies here, and we all know that Vista is the problem.
>
> That said, we also need to thoroughly understand what is going on, and to clearly see exactly what the problem is. (Exactly means: win32 api call X when used in DBISAM, performs Z times slower on vista, or such).
>
> From my desk, I can see that a given piece of code is running not 10x slower, but 20-80x slower on vista. It is unusable slow. It makes our software, which flies on XP, simply unusable on vista.
>
> And this code is DBISAM.
>
> So here is where I need your help. I apologize, but I lack the time to dig through DBISAM. I am really sorry I cannot deliver this on a silver platter. (I would like to!)
>
> We need, from Elevate, a look at this issue. We need to know:
>
> a) What the Win32 call is that kills DBISAM
>
> b) Is there a simple workaround we can use in DBISAM that preserves our overall approach?
>       (perhaps it is a message pumping problem, or ???)
>
> c) Once the problem is understood, perhaps there will be an adjustment to DBISAM itself to work around the issue.
>
>
> I hope we can all appreciate that we can't just take a hammer out. The approach we use with DBISAM (of flushing buffers, etc) we arrived at after much shed blood (trashed data, etc etc). We cannot just 'undo' our approach. The approach
> we use is a DBISAM supported approach, and has been thoroughly tested by us, and has proven itself in the field.
>
> But there is a problem on vista. A HUGE problem.
>
> Please lend a hand as soon as is feasible.
>
> Thank you so so much!
>

Sam,

<< a) What the Win32 call is that kills DBISAM >>

As I indicated before, the call is FlushFileBuffers.

<< b) Is there a simple workaround we can use in DBISAM that preserves our
overall approach? (perhaps it is a message pumping problem, or ???) >>

No.  The problem is that the OS is executing the function in a different or
unpredictable manner, therefore the workaround would be to stop using the
automatic buffer flushing under Vista and revert to a more selective set of
calls to the TDBISAMTable or TDBISAMQuery FlushBuffers method.   BTW,
Windows API calls don't use messages or interact with the application's
message loop other than those calls whose purpose is to do so.  The file I/O
calls are straightforward blocking calls unless you use I/O completion
ports, which we don't.

<< c) Once the problem is understood, perhaps there will be an adjustment to
DBISAM itself to work around the issue. >>

The problem is already understood (Vista), and there is no adjustment that
can be made to DBISAM to work around it.  DBISAM is simply acting as an
intermediary between your application and the OS.  In other words, if you
turned off the buffer flushing in DBISAM and directly called
FlushFileBuffers on the DBISAM table file handles after every insert,
update, delete, etc., you would run into the same issue.  You can take
DBISAM out of the loop and have the same issue.

<< I hope we can all appreciate that we can't just take a hammer out. The
approach we use with DBISAM (of flushing buffers, etc) we arrived at after
much shed blood (trashed data, etc etc). We cannot just 'undo' our approach.
The approach we use is a DBISAM supported approach, and has been thoroughly
tested by us, and has proven itself in the field.

But there is a problem on vista. A HUGE problem. >>

Yes, and the problem *is Vista*.  I can't do anything about that.  Hopefully
Vista SP1 will fix these issues when it is released.

--
Tim Young
Elevate Software
www.elevatesoft.com

Update:

As we currently understand it, the problem is that the win32 call: FlushFileBuffers was
'broken' on XP and Win2000, and is now 'fixed' in Vista.

From our research, pre-Vista, the FlushFileBuffers did not necessarily flush everything to
disk, but on Vista it really really does. So the perf hit is really real.

This explains our earlier research.  

Many moons ago, when we first implemented FlushBuffers in DBISAM, we did a perf analysis,
and found that FlushBuffers had almost zero perf hit. So it was a no brainer, implement
FlushBuffers  session wide.
Now Vista is truly flushing, and perf dies....  So we will move to using it at the table
level....


We do not expect this to be fixed in vista... it looks to be as intended...

Sam

<<As we currently understand it, the problem is that the win32 call: FlushFileBuffers was
'broken' on XP and Win2000, and is now 'fixed' in Vista.>>

"Wow". That explains why we are having many corruption cases, even if we were using FlushBuffers. Could you post the link where did you found it?
Thanks for the update.

Mauricio Campana Nonino
Nonino Software

<<As we currently understand it, the problem is that the win32 call: FlushFileBuffers was
'broken' on XP and Win2000, and is now 'fixed' in Vista.>>

"Wow". That explains why we are having many corruption cases, even if we were using
FlushBuffers. Could you post the link where did you found it?
Thanks for the update.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Vista should not be leading to any corruption, AFAIK. Just slower perf.

The evidence we have:
 
  See: http://groups.google.com/groups/search?hl=en&qt_s=1&q=vista+FILE_FLAG_NO_BUFFERING+

 This discussion of the FILE_FLAG_NO_BUFFERING  flag :

http://groups.google.com/group/microsoft.public.win32.programmer.kernel/browse_thread/thread/f293ccabfe90af21/3cce4e31cfdcae09?hl=en&lnk=st&q=vista+FILE_FLAG_NO_BUFFERING+performance#3cce4e31cfdcae09

 The  March 02, 2008 entry here:   http://www.codinghorror.com/blog/