none
FileVersionInfo.GetVersionInfo incredibly slow under mysterious conditions RRS feed

  • Question

  • I was looking at a customer issue today and discovered that they were experiencing slowdowns in our application.  I isolated it to the FileVersionInfo.GetVersionInfo() call which we invoke on an install image of our product.

    This is an installshield image about 400 MB in size.  The file is located on a network share.   The invocation of this method takes anywhere from 10-20 seconds in the customer environment.  Here in-house we located a machine exhibiting the same problem.  On this machine it takes 18 seconds (or 171 seconds if on wireless).    My development machine takes 5ms for the same call to the same network file.  Why the difference?

    The in-house machine with the problem is a windows 8 machine, but our customer claims they're seeing the issue on win7 as well.  Does anyone have any idea why 2 different machines on the same network using hard lines would see a swing from 5ms to 18 seconds to make the same API call?



    • Edited by GoTeamVenture Tuesday, May 7, 2013 7:40 PM Corrected API name
    Tuesday, May 7, 2013 7:35 PM

Answers

  • I agree that on the surface it looks like that but something else goes on.  On the in-house machine that took 18 seconds I fired up the network performance monitor and while this method is being run the network reads spike upwards of 150 Mbps!   There's a bit more to this than just extra network hops.

    Even at the customer site I had tried a ping to the file server and it was 1ms so something else is at play here.

    The first thing I wondered was if that method call had to open the file, or if it just read meta data.  I checked the documentation but didn't see an immediate answer so I assumed that surely it would only read meta data.

    But that is a lot of network traffic for what would be a small amount of meta data!  So now I wonder again, is it trying to open the file?  What if you perform a test with a tiny file instead of a huge one...?

    Keep in mind that there are many ways to cause network congestion and just looking at a single connection or a few ICMP packets may not be enough for a full diagnosis (they can be quick ways to spot a problem, but just because those results seem normal it does not guarantee that everything is ok... if you have layer 3 switches you would be better to get performance data from there).

    And there is still the question of the software environment within the problem machines...


    Reed Kimble - "When you do things right, people won't be sure you've done anything at all"

    Wednesday, May 8, 2013 3:15 PM
    Moderator

All replies

  • Sounds like it is a network performance issue.... especially given the huge difference in wired versus wireless.  Perhaps your development machine has a shorter or cleaner path to the server than the problem machine (and what performance details do you have for the client network?).

    If you do pings and tracerts from the desktops to the servers do you notice a correlation in latency or packet loss?

    Keep in mind that with network traffic you could also be facing any number of software issues on a particular client, including "security" software fiddling with your socket connection or data stream.


    Reed Kimble - "When you do things right, people won't be sure you've done anything at all"

    Tuesday, May 7, 2013 8:27 PM
    Moderator
  • I agree that on the surface it looks like that but something else goes on.  On the in-house machine that took 18 seconds I fired up the network performance monitor and while this method is being run the network reads spike upwards of 150 Mbps!   There's a bit more to this than just extra network hops.

    Even at the customer site I had tried a ping to the file server and it was 1ms so something else is at play here.

    Wednesday, May 8, 2013 12:17 PM
  • I agree that on the surface it looks like that but something else goes on.  On the in-house machine that took 18 seconds I fired up the network performance monitor and while this method is being run the network reads spike upwards of 150 Mbps!   There's a bit more to this than just extra network hops.

    Even at the customer site I had tried a ping to the file server and it was 1ms so something else is at play here.

    The first thing I wondered was if that method call had to open the file, or if it just read meta data.  I checked the documentation but didn't see an immediate answer so I assumed that surely it would only read meta data.

    But that is a lot of network traffic for what would be a small amount of meta data!  So now I wonder again, is it trying to open the file?  What if you perform a test with a tiny file instead of a huge one...?

    Keep in mind that there are many ways to cause network congestion and just looking at a single connection or a few ICMP packets may not be enough for a full diagnosis (they can be quick ways to spot a problem, but just because those results seem normal it does not guarantee that everything is ok... if you have layer 3 switches you would be better to get performance data from there).

    And there is still the question of the software environment within the problem machines...


    Reed Kimble - "When you do things right, people won't be sure you've done anything at all"

    Wednesday, May 8, 2013 3:15 PM
    Moderator