Short answer: no.
Long answer: I assume when you write "size" of an object, you mean size (in bytes) of the member variables, and when you write "complexity", you mean number of members, number of different types used, and so on. Access to an object through a member function will result in IL code which contains
- pushing the parameters of the method to the stack
- pushing a "this" reference to the stack
- calling the function (which will result in a simple call statement at the machine code level, not depending on the object's size)
(This is a simplified model, not taking things like inlining into account, but it is sufficient for answering your question). So as you see, in none of these operations the object size itself has an influence. And neither the number and structure of other member functions.
The size only matters from a performance perspective when you copy objects around, when you store them to disk or a database, or when you are accessing the data of so many different objects that your CPU cache is not sufficiently large to hold all the data accessed. The latter might happen when the "number of objects x size of object" exceeds a certain limit, but it depends also on what other things your program does, which other data is involved. So is an accumulated effect, and I doubt it counts as "performance impact caused by access to one of its members through a reference".