Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / .NET Framework / New Users / June 2007

Tip: Looking for answers? Try searching our database.

Release is slower than debug...  What's happening?

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
ThunderMusic - 01 Jun 2007 16:28 GMT
Hi,
I have a windows service that only loads a CSV file and import it's data
using SqlBulkCopy in a newly created Sql Server 2005 table using 25000 rows
batches.

If I build the service in debug mode and run it, I get descent performances.
If I build it in release mode, I would expect it to at least stay as fast
and maybe be faster, but I actually lose performance. I lose about 10%
performance.

How can this happen?

Here's what could be involved :
- SqlBulkCopy Class a IDataReader implementation as a source which
performance has been verified.
- <SqlDbTypes>.Parse(...)
- Array indexing
- Boxing and Unboxing of objects
- Generic classes (List, Dictionary, Hashtable) search by key

Thanks

ThunderMusic
ThunderMusic - 01 Jun 2007 16:33 GMT
oups
- SqlBulkCopy Class a IDataReader implementation as a source which
performance has been verified.

should read

- SqlBulkCopy Class using a IDataReader implementation as a source which
performance has been verified.

> Hi,
> I have a windows service that only loads a CSV file and import it's data
[quoted text clipped - 19 lines]
>
> ThunderMusic
Ben Voigt [C++ MVP] - 01 Jun 2007 17:17 GMT
> Hi,
> I have a windows service that only loads a CSV file and import it's data
[quoted text clipped - 7 lines]
>
> How can this happen?

Are you measuring first run performance, or steady state?

The first run requires that the JIT compiler be run, and in release mode the
JIT has to look for optimizations, hence taking longer.  After the code is
compiled, however, the incremental cost of rerunning it is usually greatly
reduced by the optimizations.

> Here's what could be involved :
> - SqlBulkCopy Class a IDataReader implementation as a source which
[quoted text clipped - 7 lines]
>
> ThunderMusic
ThunderMusic - 01 Jun 2007 18:03 GMT
Even after many runs, it's still slower.

>> Hi,
>> I have a windows service that only loads a CSV file and import it's data
[quoted text clipped - 26 lines]
>>
>> ThunderMusic
Peter Bromberg [C# MVP] - 01 Jun 2007 18:33 GMT
ThunderMusic,
This simply "does not compute". Are you actually installing this windows
service after it has been built in a debug build configuration? And you are
comparing the performance against  a different Windows Service installation
that was done with a release build?

What I'd do (unless you want to get into some heavy-duty profiling) is use
the Stopwatch class to take some start / finish timings around critical
operations that occur when your service runs, and write the results as
appended lines to a text file.

Examining this, if you have instrumented it properly, should give more
insight.
Peter

Signature

Site:  http://www.eggheadcafe.com
UnBlog:  http://petesbloggerama.blogspot.com
Short urls & more:    http://ittyurl.net

> Hi,
> I have a windows service that only loads a CSV file and import it's data
[quoted text clipped - 19 lines]
>
> ThunderMusic
Aneesh P - 01 Jun 2007 18:58 GMT
On Jun 1, 10:33 pm, Peter Bromberg [C# MVP]
<pbromb...@yahoo.yabbadabbadoo.com> wrote:
> ThunderMusic,
> This simply "does not compute". Are you actually installing this windows
[quoted text clipped - 41 lines]
>
> - Show quoted text -

I was using same kind of functionality, but in the reverse way,
loading data from SQL to CRM Server and then to MSMQ. Again from queue
to a CSV file. The performance is considerably better when I built the
windows service in release mode. I've found it out using the
aforementioned Stopwatch class. I'd venture to suggest the same.
ThunderMusic - 01 Jun 2007 19:42 GMT
Hi,
Thanks for the answers...

1) Yes, it's the same service I'm testing, in debug, then in release (or in
release then in debug, no importance, I get the same results) and always on
the same computer.
2) The thing is, We are already logging when the application reach an
important point (with Timestamps). So using Stopwatch here will only add
overhead to the process. Actually, we are taking a 4000000 rows CSV and copy
it to a SQL Table by taking care the datatypes are good. So we optimized our
process and managed to get a good performance (by replacing most of the
generics by native arrays, using temporary variables instead of always
getting the current value from the file reader, et al.) maybe we optimized
"too much" and the JIT cannot find a way to optimize intelligently... Would
it be possible?

Thanks

ThunderMusic

> On Jun 1, 10:33 pm, Peter Bromberg [C# MVP]
> <pbromb...@yahoo.yabbadabbadoo.com> wrote:
[quoted text clipped - 56 lines]
> windows service in release mode. I've found it out using the
> aforementioned Stopwatch class. I'd venture to suggest the same.
AMercer - 02 Jun 2007 13:01 GMT
> If I build the service in debug mode and run it, I get descent performances.
> If I build it in release mode, I would expect it to at least stay as fast
> and maybe be faster, but I actually lose performance. I lose about 10%
> performance.
>
> How can this happen?

A stab in the dark ... Do you handle many exceptions?  My experience is that
executing a 'try' gives no noticeable performance hit, but executing a
'catch' is very noticeable.  So... maybe the non-catch part of your code runs
slower in debug (as intuition dictates), and maybe the catch parts of your
code run much slower in release (not sure why, perhaps there is more to
untangle).  As I said, a stab in the dark.
Jon Skeet [C# MVP] - 02 Jun 2007 19:29 GMT
> > How can this happen?
>
[quoted text clipped - 4 lines]
> code run much slower in release (not sure why, perhaps there is more to
> untangle).  As I said, a stab in the dark.

Catching an exception *in the debugger* takes a vast amount of time.
Catching an exception in a release build, not running in the debugger,
takes relatively little time. Unless you're throwing and catching
thousands and thousands of exceptions, there shouldn't be any
significant performance hit.

Signature

Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet   Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

ThunderMusic - 04 Jun 2007 13:35 GMT
No, I'm not throwing many exceptions. Actually, with the test we ran, none
were thrown. so it must be in the non-catch part... ;)

We still experience the problem independantly from being executed after a
reboot or after running a while. We tried to measure with StopWatch, but
nothing relevant came out of this because when run in a close loop,
StopWatch tend to add overhead and it almost doubled our processing time.
(in the file we are testing, we do a 4000000 iteration 'for' (rows, records)
with an inner 13 iteration 'for' (columns, fields). So if we try to measure
the total time doing parse and total time for writing in the array to send
to bulk copy and the total time of anything, the StopWatch make make it go
awry

Would you have any other ideas so we can find what is going on?

Thanks

ThunderMusic

>> > How can this happen?
>>
[quoted text clipped - 13 lines]
> thousands and thousands of exceptions, there shouldn't be any
> significant performance hit.
Willy Denoyette [MVP] - 04 Jun 2007 15:49 GMT
> No, I'm not throwing many exceptions. Actually, with the test we ran, none
> were thrown. so it must be in the non-catch part... ;)
[quoted text clipped - 14 lines]
>
> ThunderMusic

I don't get is, when using StopWatch doubles the processing time, it looks
like you have your StopWatch calls at the wrong places, so I'm currious
where you inserted the StopWatch calls, my guess is for each iteration,
which is wrong when each iteration executes only a few statements. Mind to
post some code?
Also, did you compare the GC counters like Time Spent in GC and the number
of Collections done for each generational heap when running both release and
debug versions?

Willy.
ThunderMusic - 04 Jun 2007 21:08 GMT
>> No, I'm not throwing many exceptions. Actually, with the test we ran,
>> none were thrown. so it must be in the non-catch part... ;)
[quoted text clipped - 25 lines]
>
> Willy.

For the StopWatch, we tried to nail down a section of the code where the
processing is slower in release, but because of the structure of the code,
we cannot place it elsewhere than inside a loop because all the work is done
in a loop. So it's really hard to know exactly where we must look.

I cannot post code because it would be a violation of my contract because I
can't just simplify the code mainly because the problem could be anywhere in
it.

We didn't look for the GC counters... I'll look into that and come back with
the results.

Thanks

ThunderMusic

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.