1
var addr = (from s in context.Addresses
            where (s.u_address_id == new Guid(this.Id).ToString("B"))
             select s).Single();    
Address Addr = new Address(addr.u_address_id);

What is the cost of assigning a linq result to a variable instead of calling it directly in my usage as follow?

Address Addr = new Address(((from s in context.Addresses
                             where (s.u_address_id == new Guid(this.Id).ToString("B"))
                             select s).Single()).u_address_id);
4

4 回答 4

4

There is no cost in execution time or space consumption. In either case, a storage location is needed for a brief period of time. Some stack slot or register is briefly used to store a reference to the result of the .Single() call and pass it to the constructor. After that (assuming you don't use the variable again, which is heavily implied) it is not needed and can (will) be re-used.

More relevant factors could be readability, line length, coding standards, etc.

于 2012-08-29T18:20:01.603 回答
2

None. They both do the same thing, but one names a local that would be hidden otherwise.

If you're that nuts for shaving every tiny cost away, why not do:

Address Addr = new Address((from s in context.Addresses
  where (s.u_address_id == new Guid(this.Id).ToString("B"))
  select s.u_address_id).Single());

Not getting all the fields could have an impact from absolutely minute, through pretty miniscule to enough that it would almost matter.

Even better:

string add_id = new Guid(this.Id).ToString("B");
if(context.Addresses.Count(s => s.u_address_id == add_id) != 1)
  throw new InvalidOperationException();
Address Addr = new Address(add_id);

(With some sources, .Where(s => s.u_address_id == add_id).Take(2).Count() is better, with others not).

Or if you can be confident such a item exists in the source, you can just do:

Address Addr = new Address(new Guid(this.Id).ToString("B"));

None of which are massive, but they're all much greater than the concern with giving a temporary a name. I think they get increasingly clear as to what they are actually doing as we go, too. I consider the last, the most readable.

于 2012-08-29T18:42:12.537 回答
1

There really isn't much in the way of costs. You might (and yet might not) have a word or two of memory on the stack taken up for a bit longer in the first case, but that's pretty negligible in terms of costs. Readability varies a bit between the two, and that's always a bit of a subjective case. Here I'd say enough is going on that it's a bit more readable on two lines, and it could be a bit easier to debug when you aren't doing too much per line of code.

于 2012-08-29T18:21:11.963 回答
1

Well, assuming that the variable is not optimized away by either the compiler or the JIT. Then you start worrying about storing 4 or 8 byte (32 or 64 bit) in RAM or a register.

Compare that to the rest of your code where your query is translated to SQL on the fly, sent over the network to a database server, parsed by the database server, executed by the database server, the result sent back over the network, the result materialized to an object that you can use.

Are you still worried about that 4 byte assignment? I'm not.

于 2012-08-29T18:30:26.947 回答