Console app runs at same speed on all machines

[John Bailo]

I wrote a console app that reads some fields from a database, does some
string parsing and writes the fields to a text file.

The slow step in loop is the string parsing.

I ran my code on 4 different machines, 1 with single proc, 1 with dual,
and 2 with quad. There were different memory sizes available from 0.5G
to 4G.

Here's the thing:

1. The program ran at exactly the same speed on all four machines!

2. Checking the taskmanager, it never seemed to consume more than 1-2
percent of processing, even though all the machines it ran on were
relatively idle.


How/Why can this be? Can I configure the CLR to use all available
resources to make an app run faster?

 

[Jon Skeet [C# MVP]]

I wrote a console app that reads some fields from a database, does some
string parsing and writes the fields to a text file.

The slow step in loop is the string parsing.

Are you absolutely sure about that? Are you sure the time isn't
actually in getting the data from the database?

I suggest you write some sample code which has the fields prepopulated,
so it just has memory operations to do - or use a file. When you've
done that, post it as a short but complete program and we'll see what's
going on.

I ran my code on 4 different machines, 1 with single proc, 1 with dual,
and 2 with quad. There were different memory sizes available from 0.5G
to 4G.

Here's the thing:

1. The program ran at exactly the same speed on all four machines!

2. Checking the taskmanager, it never seemed to consume more than 1-2
percent of processing, even though all the machines it ran on were
relatively idle.

Then it sounds like it's not processor bound...

 

[John Bailo]

Are you absolutely sure about that? Are you sure the time isn't
actually in getting the data from the database?

Yes, I commented out the call to the parsing method, and it ran much faster.

I suggest you write some sample code which has the fields prepopulated,
so it just has memory operations to do - or use a file. When you've
done that, post it as a short but complete program and we'll see what's
going on.

Kind of hard, the code for the parsing is quite extensive.

Then it sounds like it's not processor bound...

Would c# automatically increase its use of the processor as needed?

 

[Jon Skeet [C# MVP]]

Yes, I commented out the call to the parsing method, and it ran much faster.

Hmm. Does the parsing method take much memory? Does it involve any IO?

Kind of hard, the code for the parsing is quite extensive.

I suggest you run a profiler then...

Would c# automatically increase its use of the processor as needed?

Absolutely.

 

[John Bailo]

Jon Skeet [C# MVP] wrote:

Are you absolutely sure about that? Are you sure the time isn't
actually in getting the data from the database?

Yes, I commented out the call to the parsing method, and it ran much faster.

Hmm. Does the parsing method take much memory? Does it involve any IO?

No, it's pure string manipulation.

I notice that things like foreach loops and indexof's seem to take a
long time.

It's also "highly object oriented" -- each part of the string
manipulation is done in its own class. These inherit a common interface
and an abstract class as its base.

I suggest you run a profiler then...

Good idea!

Can I easily run that from VS.2003?

 

[Jon Skeet [C# MVP]]

(As I say in my sig, please don't mail me with a copy of your post)

No, it's pure string manipulation.

I notice that things like foreach loops and indexof's seem to take a
long time.

That's very odd. In particular, I'd expect that to be very CPU
intensive.

Can you take out *bits* of your string parsing, to work out what's
taking the time? If you can work out which bit is being particularly
slow and post that, we're more likely to be able to help.

Just to check: are you running this under the debugger or not? You may
find there's a vast difference in execution speed. It does sound like
you're blocking on something else completely though.

It's also "highly object oriented" -- each part of the string
manipulation is done in its own class. These inherit a common interface
and an abstract class as its base.

That should be okay.

Good idea!

Can I easily run that from VS.2003?

I'm sure you can - but to be honest, I've never needed a profiler so I
wouldn't know which to recommend.

MS has a free profiler you can download:

http://www.microsoft.com/downloads/details.aspx?FamilyId=86CE6052-D7F4-
4AEB-9B7A-94635BEEBDDA&displaylang=en

 

[John Bailo]

That's very odd. In particular, I'd expect that to be very CPU
intensive.

Me too.

Can you take out *bits* of your string parsing, to work out what's
taking the time? If you can work out which bit is being particularly
slow and post that, we're more likely to be able to help.

Yes, I need to do that! Will the profiler tell me that? I'm going to
download what you suggested below...

Just to check: are you running this under the debugger or not? You may
find there's a vast difference in execution speed. It does sound like
you're blocking on something else completely though.

I ran it both in the Debugger as a debug version, and outside as a debug
version and outside (command line) as a release version. But no change.

 

[Jon Skeet [C# MVP]]

Yes, I need to do that! Will the profiler tell me that? I'm going to
download what you suggested below...

Yes, the profiler should tell you that. But I would hope you'd be able
to do the same kind of thing yourself.

I ran it both in the Debugger as a debug version, and outside as a debug
version and outside (command line) as a release version. But no change.

Very, very odd. I'll be interested to find out what's wrong.

If you can't post your code, is there any chance you could mail it to
me with some sample data? I'm happy to make any non-disclosure promises
you want

 

[John Bailo]

Jon,

This is a good profiler, but it seems to recommend me against using it:

"CLRProfiler is an intrusive tool; seeing a 10 to 100x slowdown in the
application being profiled is not unusual. Therefore, it is not the
right tool to find out where time is spent – use other profilers for that."