Here's what I
think. And, yes, I know I should
test before making statements about performance, but ...
Breaking a big class into several little classes is a good idea, for program maintainability, iff the break-down is "natural". But, from maintainability point of view, splitting a class just because it "looks too big" generally makes things worse.
From the point of view of memory, there is a smallish overhead in having several small classes, rather than one big class. However, this only applies if your application will use all the facilities of the big class. If your application only uses a small proportion of the facilities of your big class, then it still has to load the whole big class. If, on the other hand, you split your big class intelligently, then it may be that your application may never need to load some of the small classes.
With regard to methods, it is my view that, for maintainability, they should never be very long. Ideally, each method should fit on the screen in a typical editor. This makes it much easier to see what's going on, providing that all the methods called by your method have helpful names. It is easier to refactor and reuse code that is in small chunks, rather than big monolithic slabs. Documentation and debug checks are easier, because you can document the values that each small method expects to receive and can test for them at the start of each method.
From the performance point of view, there is a small gain in having one big method, rather than several small methods, because you save the overhead of the extra method calls.
From the memory point of view, there is again a small gain in having one big method, providing that you do not duplicate code.
An aside: duplicating code can occasionally be worthwhile, in the most performance-critical parts of your code. For instance, one technique is "loop unrolling" where, instead of executing your loop N times, you duplicate the content of the loop, say, 3 times, and execute your loop N/3 times.