The reality is that with modern code, it's so far removed from the underlying machine language that gets executed that there's no point trying optimisations at the level of a break vs setting the iterator. Optimisations nowadays are at architectural levels - managing tight loops, using appropriate data structures, parallelisation, resource access.

Quote:

but then I wouldn't write that code by hand. Too error prone.

Isn't this exactly the point? All code gets compiled/interpreted/translated to jmps eventually. The goals of the written code should be correctness, understandability and simplicity. Leave the gotos and the clever techniques to the compiler.

DateTime is a ValueKind, so comparing it with null isn't very useful (it'll always not be null). If your LINQ query doesn't find any rows, then FirstOrDefault() will return a default instance of the requested data type (DateTime, in this case). There's a clue in the name ;) If you want to know if you found any rows or not, either test the query first (e.g. Any()) before evaluating First(), or compare the returned value with the default DateTime value (DateTime.MinValue, IIRC). If you do that however, you won't be able to tell the difference between no rows, and rows where the first had the minimum datetime value.