I want to second BrowserUk's point about OO vs. speed. One of the central strategies behind OO is indirection, often multiple levels of it. The idea is that by introducing levels of indirection one decouples various parts of a program.

For instance, the use of accessors introduces one level of indirection, because instead of accessing the data "directly" (through, say, $obj->{ field }), one accesses it "indirectly" by calling $obj->field which in turn accesses $obj->{ field }. This trick decouples all the parts of the program that access this data from the parts of the program that implement the storage and management of the data, so that the latter can be altered, possibly radically, without this having any effect on the code for the former. (I see the accessor is being something reminiscent of a "hinge" between two parts of the code.)

Once you grok this indirection business, you'll see it at work everywhere, and in many guises, even in code that is otherwise not terribly OO.

This decoupling greatly eases the task of maintaining code, but it comes at a price performance-wise. I see this tension as being obviously fundamental (i.e. unresolvable), although I have found people who reject this view. tilly sparked a very interesting exchange on this subject recently; see also this.