What is an expensive method or resource?
It is often mentioned that exceptions are expensive, and various methods in .NET are expensive too.
What exactly is an expensive method in .NET?
Is it the time taken to process the process? EG. I got a web page response stream using a WebClient object (it was not asynchronous) and after getting the response and assigning it to a variable it took a while to go through this line of code. Perhaps because the web page itself was graphic-intensive and large. To find out the time, I know that I can use a stopwatch or a timer (there is a subtle difference between the two that I cannot remember).
Or is it taken resources? If so, what is the best way to see the resources the method is using? I know I can use one of the GC methods or the profiler. What other approaches are there?
source to share
An expensive question of degree and context.
I work in image processing and I find the division is expensive. In my case, any operation is added that ends up being executed two to five million times in one cycle. This can be the difference between 1/8 of a second and 1/32 of a second. 1/8 second in UI time is a lot for dynamic display. 1/32 is acceptable.
In other cases, it can be full decoding of large JPEG images and their upscaling, instead of taking advantage of two smaller versions, also encoded in the same file.
At the time of the web page, this could be the number of times the server was accessed on page load. See what I mean?
Context is everything.
Resources are considered costly if they are scarce and make other things wait. If you have 1 non-raid disk, you pay a high price for access, if two processes bounce off your head all over the place, hence heavily reliant on caching on both disk and OS.
Your printer is a very expensive resource, especially if it is down, hence the queue.
Exceptions are expensive compared to other language features. Calling a static method is cheap. A regular method call is slightly more expensive. Virtual method calls are slightly more expensive. Exceptions are much more expensive.
For example, you might complain that C # doesn't have polymorphic return types, and I might say - oh no, it does - just throw your result and catch the correct type on the other side. Then I laughed from the room to propose. Compared to returning (which is a small number of instructions), an exception can throw tens to hundreds, depending on the context.
source to share
Yes, when people talk about expensive features, they usually mean in terms of runtime. (The price you pay to call it is that your thread is blocked for X microseconds until the function call completes)
Of course, this can also be expensive in terms of resource usage, but this is usually the runtime that people refer to.
source to share
I agree with plint, but I would like to add that expensive usually implies that something requires more time or resources than you expected, or more resources than you need for a given situation. In general, something is expensive if there is an alternative that uses less CPU or resources, which is more appropriate.
For example, exceptions are considered costly due to the number of clock cycles it takes to build a stack trace. Therefore it is very bad use of exceptions as a flow control mechanism. So, if you've parsed the user data format and it has been malformed, it would probably be better to return an object with a failure status and a string (bad data line 6, item 3) rather than throwing a MalformedDataException.
But yes, it's an expensive matter of degree and perspective. For a CPU designer, a cache miss is a disaster. To spit, separation is expensive. For me, access to the hard drive is expensive.
source to share