1

I'am looking at a performance problem that showed up between two release (this is a windows app). What I observe is that the version that is slower is doing more I/O than the previous one ( I have observed this with process explorer (see graph below)) when the other one do none or very few, and the I/O are correlated with less cpu activity. So I am guessing that the performance loss come from the I/O.

But as the code is quite big, and shared by different team, it's not easy to spot what as changed. Moreover the gap between the two version is also important. From what I'am concerned this two versions should still to the same kind of job... so knowing that this app is doing file + DB access, does anybody knows a way (or a tool) to spot which portion of code may be involved into a significant I/O activity ?

I have try some profiler (ltprof) but without much luck so far. I have try to do some statistic debugging (pausing every few second) to see what the callstack is), but as the I/O seems to take a minor % of the process (say less < 15%), again I don't have find anything relevant so far.

Any idea greatly appreciated.

enter image description here

yves
  • 664
  • 1
  • 12
  • 24
  • 1
    Use a decent profiler to see where time is being spent doing I/O or whatever - I don't use Windows but apparently the Very Sleepy profiler is good: http://www.codersnotes.com/sleepy – Paul R Apr 06 '11 at 16:03
  • I found [this answer](http://stackoverflow.com/questions/375913/what-can-i-use-to-profile-c-code-in-linux/378024#378024) very useful. A very general and powerful technique (works with I/O too). – anatolyg Apr 06 '11 at 16:14
  • Don't jump to conclusions and assume it is caused by code. Having a file fragmented more, the dbase server being bogged-down more does this too. – Hans Passant Apr 06 '11 at 16:50
  • I forget to mention : I compare the two version, with a dedicated database hosted on the same hardware. But you are right, may be it's not the code. That's why anyway I need to spot which I/O is involved. – yves Apr 06 '11 at 17:05

1 Answers1

1

Process Monitor from Sysinternals (now part of Microsoft) will create a log of all the I/O operations executed by a process (or processes). It might give you a clue as to what all the extra I/Os are, though it won't point you to a specific portion of the code. You could compare the log to one from the faster version and see what's different. You might also be able to spot patterns (like redundant work, or writing back-to-front instead of front-to-back).

If the total I/O is the roughly the same, then the problem may be lock contention rather than I/O.

Adrian McCarthy
  • 45,555
  • 16
  • 123
  • 175