Just to add to what I just wrote. My philosophy with code is that most of the cost is with fixing bugs. If you write maintainable code (readable using consistent patterns throughout) backed with good unit tests, then you are minimizing a lot the cost of software development.
In open source, it doesn't really matter as the code is written mostly by one and for one. However in large projects, code which makes it easy to fix and add stuff is worth a lot more then a speedup of 5 or 10 assembly lines. My thoughts (which are worth about 1.2 cents American right now) Phil -----Original Message----- From: Philippe Lavoie Sent: Tuesday, March 25, 2003 10:19 AM To: Miguel de Icaza; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: [Mono-list] Exceptions and error codes. I think the original point made was that unless you have profiling information to back up any claim that "this part of the software" will slow you down. Then use a mechanism which will make your code more maintainable. The example below clearly has performance issues. However if the function handle_number_argument below takes 100 ms to process, the 5 or 10 extra lines of assembly added by the try/catch becomes meaningless in terms of overall performance. You'd better spend your time improving that function then rewriting the parser of Int32. Sometimes, it could be best to improve the JIT to better handle embedded try/catch statements :) Just another way of looking at it. I don't think there is a "one and true" way. It's all a grey area when you start to mix performance / maintainability / readability / philosophy, etc. Phil -----Original Message----- From: Miguel de Icaza [mailto:[EMAIL PROTECTED] Sent: Sunday, March 23, 2003 10:43 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [Mono-list] Exceptions and error codes. Hello, You do raise interesting points. The problem with exceptions is that throwing and catching an exception is an expensive operation. Using an exception as a mechanism to return a failure error, when failure is likely to happen is inefficient. Contrast `likely to happen error' with `exceptional condition: internal error, or unlikely error to happen'. Lets consider a sample: a program that uses Int32.Parse to detect whether an integer is available, or maybe a string command exists, and we are parsing, say, a million records: for (i = 0; i < one_million; i++){ string line = readline (); try { v = Int32.Parse (line); handle_numberic_argument (); } catch { ParseCommand (line); } } This is so bad, that you probably want to rewrite the code to pro-actively avoid parsing things that are known not to be integers. It is easy to turn an error-code API into an exception-throwing API with no performance loss. The opposite is not possible. Miguel _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
