UITextView on iPad INCREDIBLY Slow

Question

I have an NSMutableArray of custom views (that are pretty much 1 UITextView and 1 UILabel with a custom back ground image), these are created as they are need (I start with 2 (though the first one is only 2 UITextFields and the other is normal) of these). Now my issue here seems to be this: as soon as I try to edit any UITextView past the one in the 2nd view, it starts to run incredibly slow, not the app, just the textview. For example, as I type, the little blinky guy lags behind the text and when I click to copy/paste/cut/etc you can see the little balloon fly in from the upper left corner every time. I have run the static analyzer for leaks and come up with nothing and run it alongside some other the testing software in XCode and it does not appear to have any reason for this.

Any help would be greatly appreciated.

EDIT Adding code Custom UIView, all that's really called on each

 -(id)initWithFrame:(CGRect)frame andIdentifier:(NSInteger)_t {
if ((self = [super initWithFrame:frame])) {
    // Initialization code
    self.image = [UIImage imageNamed:@"page.png"];
    self.tag = _t;
    self.userInteractionEnabled = YES;
    self.clipsToBounds = YES;

    drawImage = self.image;

    text = [[UITextView alloc] initWithFrame:CGRectMake(40.0, 40.0, self.frame.size.width - 80.0, self.frame.size.height - 80.0)];
    text.delegate = self;

    Lbl = [[UILabel alloc] initWithFrame:CGRectMake(self.frame.size.width - 30, self.frame.size.height - 30, 20, 20)];
    Lbl.text = [NSString stringWithFormat:@"%d",self.tag];

    [self addSubview:text];
    [self addSubview:Lbl];

    [Lbl release];
}
return self;

After that, I store the view in an array in the view controller and then stack 2 (used to be 3) at a time with one front and foremost and one below it. These get shuffled a bit but thats about it. I do not think it is a device issue, just a weird error that I cannot seem to catch.

Answer 1

found my problem, apparently some obscure animation block got left opened, which apparently animated everything else that was going on on the UIKit side. odd but makes sense