Suggestion: More Member Statistics for a Type in Super Quick Infos

[fitdev]

It would be very nice if Super Quick Infos for classes, structs, and interfaces would show basic statistics such as:

• Field count (const, static, instance)
• Property count (static and instance)
• Method count (static and instance)
• And for completeness perhaps: events, operators, indexers.

Ideally for classes this should include a breakdown into self vs inherited, so the notation could be self + inherited = total.

It would be optional, as with most other Super Quick Info elements.

And ideally, it would also include object size in memory by calculating all the instance fields (we can assume 64 bits, but perhaps we should show both varieties for 32 and 64). This is particularly useful when deciding on the architecture - inheritance vs containment for example, to minimize memory footprint. Though it may require a bit more work to implement correctly when StructLayout and FieldOffset attributes are involved.

[wmjordan]

The "basic statistics" does not make sense for me, thought it is easy to implement that.

The object size information is requested similarly in #239. Unfortunately Roslyn does not expose any API to do that.

[fitdev]

Statistics are very useful when you are redesigning / refactoring / rearchitecting, or when basing new types on existing ones, so that you can come up with the more optimal API. Having this information in the tooltip saves quite some time as you don't have to open the code file itself, look in the NaviBar, etc. - very useful if you are comparing / contrasting several types and just want to see such info quickly.

As for the object size - couldn't this be manually implemented by looking at the instance fields recursively?

1. Classify a field as a reference type or a value type.
2. If reference type (class, interface, string): it is basically 4 or 8 bytes.
3. If it is a value type, determine which general case it belongs to:

• Enum: Use enum's underlying numeric type
• Bool, Numeric: Depending on the numeric type it would be anywhere from 1 to 16 bytes
• Nullable: 2 * sizeof(T)
• Struct: Recurse this algorithm to get the underlying fields

Even if it is not exact runtime object size (as we are ignoring StructLayoutAttirbute), it is still very useful to just be able to see at a glance object's footprint in memory. It can then influence all kinds of decisions more easily: inheritance relations, parameter passing (do we add in/ref modifiers to pass by reference), etc.

[wmjordan]

I still can not understand why number of properties, methods or other members matters. By refactoring, you can increase or reduce members but keeping the code logic the same. A type with 3 methods is not obviously better or worse than another one with 10 methods.

As for the object size topic, the calculation algorithm above does not consider object packing. For instance, a struct with an int field plus a bool field may actually take up 8 bytes instead of 5. I don't know how runtimes (.NET Framework, or newer versions of .NET Core) do that type of memory layouts.

For instance, given the following structs:

struct M { int a; bool b; }
struct M2 { int a; bool b; bool c; }
struct M3 { bool x; int a; bool b; }

The size of either M or M2 is 8, but M3 is 12.

Codist might guess the behavior of CLR, but it is not accurate.

[fitdev]

It helps a great deal when you are planning your APIs. I have a codebase with many thousands of types, a lot of which I have not used in a year or more, and it helps a great deal to get such summary statistics when you are considering extensions to those types or new types, or improvements to APIs, etc. It is not an issue when you have a few hundred types and all of them are relatively small with shallow inheritance hierarchy, because you kind of know all of them by heart, but once your codebase grows and reaches a certain size, any help you get becomes quite important.

As for the object size. Yes, I know that it won't consider object packing or layout. However I think it is still much better than not having it at all, as it still gives you an idea of how large an object is. Again, this becomes important when your codebase is large, and you want to avoid manually opening every code file to see exactly how much of what it contains.

For reference-like fields (interfaces, classes, strings, ref fields, and pointer*-s) it could just show their count and range of bytes (i.e. 12/24 - one for 32 bits and one for 64 bits).

For all other cases, it would just use actual values based on the underlying type and show their sum.

[wmjordan]

a codebase with many thousands of types, a lot of which I have not used in a year or more, and it helps a great deal to get such summary statistics when you are considering extensions to those types or new types, or improvements to APIs

I still did not read the point.
Actually the VS SDK itself does contain the same scale of amount of types. But we program against the semantics and functionalities of the types, not the numbers.
For instance, the Microsoft.VisualStudio.Imaging.KnownImageIds class approximately contains 3761 members, but what if it contains 3760 or 3763? And System.Windows.Media.Brush in the .NET Framework contains 108 members, 24 are defined and 84 are inherited. But what's so important from those two numbers?

BTW, the List Members command does show you some counts.

[fitdev]

But what's so important from those two numbers?

It helps you a great deal when you are developing / extending / modifying _your own code base _ (as opposed to simply consuming a framework or another library). It helps you make more informed decisions.

BTW, the List Members command does show you some counts.

That's a good point, and it is very useful. It's just that you have to do a few clicks to get to this information, which again adds up quickly if you are exploring / familiarizing yourself with a code base.

BTW, as an aside, I wish the member lists had more granularity in their filters (for example, right now properties and fields are grouped under a single toggle - I may want to be interested in just instance fields for example).

[wmjordan]

I wish the member lists had more granularity in their filters (for example, right now properties and fields are grouped under a single toggle - I may want to be interested in just instance fields for example)

Well, some properties are actually methods. It makes sense to separate fields and properties.

[wmjordan]

However I think it is still much better than not having it at all, as it still gives you an idea of how large an object is

Well, it is possible to calculate a theoretically minimal byte count of a struct with Roslyn.
Let me think about it when I have time.

[wmjordan]

I studied the implementation of Roslyn, the minimal byte count only works for structs, not classes, since Roslyn only returns private fields for structs. For classes, we have no approach to calculate its minimal memory consumption, since we don't have access to private fields.

[fitdev]

Thank you for looking into this. That's strange that it would only support structs. Still, structs is better than nothing. And perhaps it can still be done for user code - all those classes defined in the code and not coming from the libraries.

[wmjordan]

perhaps it can still be done for user code - all those classes defined in the code and not coming from the libraries.

It is impossible when the class inherits a class from an external assembly.
For instance, if a class inherits List<int>, Roslyn does not return the private fields of List<int>, thus it is impossible to calculate byte consumption for the class.

[fitdev]

Yes, I know. I meant for the cases where the entire inheritance chain is in the user code. But, maybe it's too much, so struct-only version would be ok. Perhaps later if they introduce ability to discover fields in classes, this can be revisited.

Pretty bad that Roslyn is limited in this regard (for example I am still hoping they will add an API for implicit/explicit operator usages, as it would be great if Codist could find those).