Geek Answers Handbook

What is the cost of casting parameters

When working with MVVM and Prism, I find that I do a lot of castings, since most of the parameters are interfaces

Example

public void AddCrSubSystemsToPlant(IPlantItem plantItm, CRArticleItem crItm) { OSiteSubSystem itm = (OSiteSubSystem)crItm; itm.PartData.Order = ((OSiteEquipment)plantItm).SubSystems.Count() + 1; ((OSiteEquipment)plantItm).SubSystems.Add(itm); }

or

  public void DeletePart(IPlantItem plantItem) { IEnumerable<IPlantItem> itmParent = GetParentPartByObjectId(_siteDocument, plantItem); if (plantItem is OSiteEquipment) ((ObservableCollection<OSiteEquipment>)itmParent).Remove((OSiteEquipment)plantItem); if (plantItem is OSiteSubSystem) ((ObservableCollection<OSiteSubSystem>)itmParent).Remove((OSiteSubSystem)plantItem); if (plantItem is OSiteComponent) ((ObservableCollection<OSiteComponent>)itmParent).Remove((OSiteComponent)plantItem); }

My question is what is the cost. Whether these operations are expensive memory or a processor if they should be avoided.

Any kinds?

+7
source share
3 answers

I think the more important question is why are you doing so much casting?

In the first example:
Why is the first type of parameter IPlantItem , if you continue to distinguish it from OSiteEquipment ? The same can be said about the second parameter.

In the second example:
Why IEnumerable<IPlantItem> GetParentPArtByObjectId return an IEnumerable<IPlantItem> ? If he returned ICollection<IPlantItem> , you would not have to throw on ObservableCollection<T> . ObservableCollection<T> inherits from Collection<T> , which implements both ICollection<T> and ICollection . You should be able to remove an item from the collection without even knowing its type.

Now some tips.
Do not drop the same object multiple times.
Do not do this:

 if (obj is IPlantItem) ((IPlantItem)obj).DoSomething();

Do it instead

 IPlantItem plant = obj as IPlantItem; if (plant != null) plant.DoSomething();

Use basic types whenever possible. This will not allow you to quit so much. As said before, do not apply a method call to an ObserableCollection<T> on an ICollection

Use generics. If you need type logic, create an abstract base class (or just an interface if you don't need common logic) with a common parameter. Then, implement the implementations of this class for each of the implementations of the interface. Methods may also be common. I can rewrite the second example as

 public void DeletePart<TPlantItem>(TPlantItem plantItem) where TPlantItem : IPlantItem { IEnumerable<TPlantItem> itmParent = GetParentPartByObjectId(_siteDocument, plantItem); ((ObservableCollection<TPlantItem>)itmParent).Remove(plantItem); }
+7
source

using

  ((System.Collections.IList)itmParent).Remove(plantItem);

instead

  if (plantItem is OSiteEquipment) ((ObservableCollection<OSiteEquipment>)itmParent).Remove((OSiteEquipment)plantItem); if (plantItem is OSiteSubSystem) ((ObservableCollection<OSiteSubSystem>)itmParent).Remove((OSiteSubSystem)plantItem); if (plantItem is OSiteComponent) ((ObservableCollection<OSiteComponent>)itmParent).Remove((OSiteComponent)plantItem);
+1
source

This article sheds light on how casting affects performance

http://www.codeproject.com/Articles/8052/Type-casting-impact-over-execution-performance-in

Here are some general tips for optimizing your programs based on the results obtained in the previous sections:

  • Number type conversions are usually expensive, take them out of loops and recursive functions, and use the same number types when possible.

  • Downcasting is a great invention, but the type checks used have a big impact on performance, they check object types from loops and recursive functions, and also use the "as" operator in them.

  • Acceleration is cheap !, use it wherever you need.

  • Create lightweight conversion operators to speed up user operations. Used tools
0
source

More articles:


All Articles