I run the "Duplicate Objects" inspection against my application and I see the following:
System.Drawing.Color 1190 28536
Is that right? System.Drawing.Color is a value type (struct). So, while I may indeed have 1,190 different instances of the value in memory ... there's effectively nothing I can do about it (since they don't have any reference that could be shared).
Perhaps there could be some option to exclude value types from the "Duplicate Objects" checking?
(On the other hand, it is useful to count duplications of value types that happen to have been boxed).
Regards,
Jeremy
"Duplicate Objects" Inspection and Value (struct) types.
-
- Posts: 7
- Joined: Wed May 28, 2014 8:45 pm
-
- Posts: 6172
- Joined: Wed Aug 11, 2004 8:37 am
Re: "Duplicate Objects" Inspection and Value (struct) types.
Hi Jeremy
Thank you for the suggestions.
We'll add the option exclude unboxed value types. I've added a feature request.
For example, if you have millions of objects with an instance field of type Color which is the same in 95% of them, you may consider a class hierarchy with a method returning the color, which in the base class returns that most popular color (and thus does not allocate a field to store it), and a subclass to store a custom color in a field.
Another example: redundant data structures. The value type stored in each instance of class Foo is not actually a property of individual Foo, but is the same for all Foo instances belonging to the same FooGroup, and can instead be stored in there. If you have millions of Foo and only a few FooGroup this approach will same memory.
Anyway, the inspections, this one and others, just show some interesting facts about the application, interesting statistics, which hardly can be found by manually analyzing individual objects. It's up to developer interpreting the results to decide whether an improvement is needed and possible.
Best regards,
Anton
Thank you for the suggestions.
We'll add the option exclude unboxed value types. I've added a feature request.
In many cases you can do nothing about it, but not always.there's effectively nothing I can do about it (since they don't have any reference that could be shared).
For example, if you have millions of objects with an instance field of type Color which is the same in 95% of them, you may consider a class hierarchy with a method returning the color, which in the base class returns that most popular color (and thus does not allocate a field to store it), and a subclass to store a custom color in a field.
Another example: redundant data structures. The value type stored in each instance of class Foo is not actually a property of individual Foo, but is the same for all Foo instances belonging to the same FooGroup, and can instead be stored in there. If you have millions of Foo and only a few FooGroup this approach will same memory.
Anyway, the inspections, this one and others, just show some interesting facts about the application, interesting statistics, which hardly can be found by manually analyzing individual objects. It's up to developer interpreting the results to decide whether an improvement is needed and possible.
Best regards,
Anton
-
- Posts: 6172
- Joined: Wed Aug 11, 2004 8:37 am
Re: "Duplicate Objects" Inspection and Value (struct) types.
Hi Jeremy
Newest builds offers the option to exclude unboxed value types.
Best regards,
Anton
Newest builds offers the option to exclude unboxed value types.
Best regards,
Anton