I am not sure if this question is not silly, but I really want to get some opinions. I will directly provide an example of what I am currently working on.
I am using HtmlAgilityPack to parse some HTML pages.
I have a method in my code which receives the HtmlDocument and does the parsing. Currently, the code is like this :
private void OperateOnDocument (HtmlDocument pageSource)
{
HtmlNode node;
node = pageSource.DocumentNode.SelectSingleNode (/*XPath to find a node */);
// do some operation on the extracted HtmlNode.
node = pageSource.DocumentNode.SelectSingleNode (/* XPath to find another node */);
// do some operation on the newly acquired node.
// Likewise, reuse the same reference variable "node" to extract all the nodes and operate on them.
}
Pros : A single reference variable is used to operate on all the nodes.
Cons : You dont know what node an individual parsing extracts, as all the extracted nodes have different value and purpose (One node may contain rate, another may contain city name.)
Another way of doing this is :
private void OperateOnDocument (HtmlDocument pageSource)
{
HtmlNode idNode = pageSource.DocumentNode.SelectSingleNode (/*XPath to find the node containing id*/);
// parse the text and store it in string.
HtmlNode rateNode = pageSource.DocumentNode.SelectSingleNode (/* XPath to find the node containing the rates */);
// parse the text into decimal.
// Likewise, use separte meaningful names of reference variables to extract all the nodes and operate on them.
}
Pros : Separate meaningful name to each node being operated.
Cons : At times, the number of operations may mount to 10; hence, 10 different reference variables.
So, my question is if the second method is really worth doing? Or it can prove a bit expensive because of so many reference variables? How expensive are such variables in .Net? or any other language/framework in general?
If you're worried about the cost of doing something, then measure it. If you can't measure a difference, then the difference can not possibly matter (if it mattered, you'd be able to measure it).
To answer your more specific question, a variable does not have any intrinsic cost. Variables do not exist in the code that is actually executed on the CPU. They are a source-level construct, and the compiler is not obliged to create some kind of 1-to-1 mapping between source code variables and, say, push instructions executed, or registers used, or anything else. A single variable in your code can correspond to the use of several different registers (the compiler might choose to move it around from time to time), or several different variables might all end up sharing the same register because they're never used at the same time.
One of the many things a compiler does is determine the lifetime of a variable. When is it first used, and when is it last used? It doesn't matter when you declared it, or when it goes out of scope.
A transformation commonly used by compilers to put your code into a form more amenable to optimizations is to turn every assignment into a new, unique, variable, basically like in your second example. That's how the compiler prefers to work with the code, because now it can see the dependencies clearly. In the first case, it looks as if the same variable has to exist throughout the function, and be reused for both operations. In the second case, we can easily see that they're separate, independent, variables, and we can see that their lifetimes do not overlap (idNode is not used after the declaration of rateNode).
Both versions will likely produce the exact same code, but the second version is closer to what optimizing compilers do to the code internally.
My understanding is that it doesn't matter very much. The compiler (in release mode!) has a good idea of the usage of a variable. It should be able to detect that idNode is no longer used at the point where you assign rateNode, so might even re-use that memory location.
See also this question.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With