Currently all type accesses (cs.uint8) go through __getattr__, and if it's not a constant, cstruct.resolve(). This is very slow. We should look into if there are any reasons why we can't resolve types eagerly and set them as instance attributes on the cstruct object. This would make type accesses a lot faster.

Random thoughts:

• There may be a specific reason we do dynamic resolutions with .resolve(), but how big is that use case? For example, I suppose it would allow changing the typedef of a field and have that dynamically resolve at read, but this is already not possible with compiled structures (where we resolve types at compile time). To be fair, that use case is currently still possible if you opt-out your structure for compilation.
• Maybe we should only do it for specific types of things, for example enum, flag, struct and constant definitions. And then we can catch typedef with the existing __getattr__. That way we do allow for dynamic type changes, but not for things that are supposed to be static. Since dynamic typedef'ing would be an advanced topic anyway, the intended "workaround" for that would be to use typedef and use the typedef'd name instead of the struct name. "Performance oriented code" could then use the raw struct and enum names for a faster access time (properly written code utilising cstruct already does this to make the loop count in .resolve() as low as possible).