SalFile vs VisFile functions

[Dave Rabelink]

I never worried about the difference between SalFile and VisFile functions before concerning performance, but recent events at our company gave me reasons to investigate.

Last month, the company was infected by a virus and the security department installed a newer version of McAfee/McShield and set the scanning mode to paranoia.
So all workstations in production are running now in these changed settings.

After this, we got reports the application we build is extremely slow in some cases. Menus which pop up instantly before took about 4 seconds to open.
Data send to servers are getting there too late.

We discovered that when we disable the logging of the application (at key points a log is written with functional/technical info on the local workstation) the performance drop was gone.

Looking at the code, it is just something like this:

Code: Select all

If SalFileOpen( fhLog, sFile, nFlags )
   Call SalFilePutStr( fhLog, "Some text to log" )
   Call SalFileClose( fhLog )

I changed the code (as a testcase to see if there is a problem with SalFile* functions) to :

Code: Select all

If VisFileOpen( fhLog, sFile, nFlags ) = VTERR_Ok
   Call VisFileWriteString( fhLog, "Some text to log" )
   Call VisFileClose( fhLog )

And to my surprise, the Vis implementation is 2 times faster.

When I disable the McShield service, the difference is minimal, but while running McShield the performance is getting very low.
The Vis functionality is slow also, but at least 2 times faster compared to Sal.

So, my question is : why is the Vis code faster? Seems the internal coding, the way how the files are accessed is causing McAfee to scan the file more thorough.

On my home workstation running Nod32 anti-virus, I do not see the huge performance difference.

So i would like to ask you, to use the testapplication in this post and see if there are performance differences between Sal and Vis on your setups (having other virusscanners).

[Ren]

Hi

We've had similar problems with F-Secure, which go away with either exceptions to files/folders or turning off the service entirely. Thanks for pointing out that it may be just a SAL vs VIS problem -- the key rule with these is not to mix them up as they break each others' file locks. That might be a key to solving this issue, but I'm sorry to say I can't help further

Too bad there aren't proper VIS-functions to handle INI-files. That would solve a lot of my problems...

[Steve Leighton]

Using the Vis* file processing functions , rather than Sal* file functions have always vastly improved open/read/write/close performance, and certainly one of the first things I change when response time is an issue. Ever since 16bit they have definitely been faster - virus scanning or not.
Not sure about SAL functions, but the Vis funcs are just pre-compiled dll's sitting ready and waiting in memory for action. The C code seems to have been written more efficiently maybe.

[Dave Rabelink]

On my setup I do not see much performance difference between SalFile and VisFile functions (at least in my test application).

As can be seen in the graph, without having a virusscan running, the times are nearly similar.
But when the virusscan is enabled, you can see a difference.

Obviously the times will be higher when a virusscanner is enabled, but I wonder about the difference between Sal and Vis in this case.
I have read on several documents some applications are 'optimized' for use with McAfee. What optimisation can be applied to speed up applications ?

The testcase shows the Vis functions are more suitable on a system using a virusscan.

I hope Unify can explain the internal difference between SalFile and VisFile functions which could affect the performance on a virusscan enabled system.