views:

107

answers:

3

So in the following bit of code, I really like the verbosity of scenario one, but I would like to know how big of a performance hit this takes when compared to scenario two. Is instantiation in the loop a big deal?

Is the syntactic benefit (which I like, some might not even agree with it being verbose or optimal) worth said performance hit? You can assume that the collections remain reasonably small (N < a few hundred).

// First scenario
var productCategoryModels = new List<ProductCategoryModel>();
foreach (var productCategory in productCategories)
{
    var model = new ProductCategoryModel.ProductCategoryModelConverter(currentContext).Convert(productCategory);
    productCategoryModels.Add(model);
}

// Second scenario
var productCategoryModels = new List<ProductCategoryModel>();
var modelConvert = new ProductCategoryModel.ProductCategoryModelConverter(currentContext);

foreach (var productCategory in productCategories)
{
    var model = modelConvert.Convert(productCategory);
    productCategoryModels.Add(model);
}

Would love to hear your guys' thoughts on this as I see this quite often.

+8  A: 

I would approach this questions a bit differently. If whatever happens in new ProductCategoryModel.ProductCategoryModelConverter(currentContext) doesn't change during the loop, I see no reason to include it within the loop. If it is not part of the loop, it shouldn't be in there imo.

If you include it just because it looks better, you force the reader to figure out if it makes a difference or not.

Brian Rasmussen
Interesting, so perhaps it's not as verbose as I thought it was. The notion of the eventual object not changing state I hadn't considered.
Brad Heller
@Brad Heller: I can't tell if it does, but since you're comparing the two as equals, I assume you don't need it.
Brian Rasmussen
+1  A: 

Keep whichever of the formats you're happiest with - if they both perform well enough for your application. Optimize later if you encounter performance problems.

Will A
+5  A: 

Like Brian, I see no reason to create a new instance if you're not actually changing it - I'm assuming that Convert doesn't change the original object?

I'd recommend using LINQ to avoid the loop entirely though (in terms of your own code):

var modelConverter = new ProductCategoryModelConverter(currentContext);
var models = productCategories.Select(x => modelConverter.Convert(x))
                              .ToList();

In terms of performance, it would depend on what ProductCategoryModelConverter's constructor had to do. Just creating a new object is pretty cheap, in terms of overhead. It's not free, of course - but I wouldn't expect this to cause a bottleneck in most cases. However, I'd say that instantiating it in a loop would imply to the reader that it's necessary; that there was some reason not to use just a single object. A converter certainly sounds like something which will stay immutable as it does its work... so I'd be puzzled by the instantiate-in-a-loop version.

Jon Skeet
Ooh, the use of link is really a great idea! I've avoided linq for a long time for some reason, this is low hanging fruit for working it in to my workflow!
Brad Heller
@Brad: LINQ is wonderful for many things. While I can understand wariness of LINQ to SQL etc (where it can be harder to predict what will work), LINQ to Objects is a no-brainer for me these days. I can barely remember C# without it.
Jon Skeet
I understand LINQ, I was just afraid that it would make my code a little less maintainable. This type of LINQ syntax is great, the more SQL-ish syntax like `(from p in Products select converter.Convert(p)).ToList();` makes me nuts.
Brad Heller
@Brad: The query expression format is great when you're doing anything complex - joins, groups etc. For simple select or where clauses, dot notation works very well.
Jon Skeet