Isn't the point of libraries and library calls to abstract away all the underlying complexity, and to leave the details open to optimizations?

Formally (as in formality, not previously), yes. But ... :)

Unfortunately, often it is the abstraction itself that is the source of the problem. Whilst abstraction can be great boon in isolating the caller from the code called, that isolation can be a double-edged sword when it comes to performance.

A trivial example, writing an RGB class, based around a blessed hash with RED, GREEN & BLUE elements, setters and getters, constructors for building them from lists of 3 values or a 24-bit integer, is a perfectly sensible approach. Especially if you wanted the basic manipulations being performed to also work on top of say, the windows GDI, which takes uses 24-bit values for colors. But using that class for manipulating the colors in images (eg.Image color swapping with GD), where the underlying API requires you to supply a list of 3 values, the performance hit of the conversions and method calls involved would be excrusiating.

Once the code has been written based around that abstraction at the lower levels, removing it completely, as opposed to substituing another underlying data mechanism whilst retaining the abstraction, would not only means wholesale changes to the calling code, it would also have incurred considerable development and testing time that would simply have to be discarded.

This is a good example of where optimisation at the lower levels would pay hansom dividends all across the board. For example, were it possible to optimise perl's methods and subroutines further (and contrasting their performance with the current crop of other, similarly dynamic languages, that doesn't seem likely), then that optimisation would benefit not only in the greater performance of procedural and OO code, but also in the removal of a barrier to greater use of abstraction.

It really is a case, again, of balance. The need to balance the theoretically correct and desirable dictates of formal methodology with the practicalities and limitations of ones environment. The tempting solution of "throw hardware at the problem" that can be so effective for high profit, low volume applications (like webservers and DB servers) suddenly becomes completely impractical for applications that sit on the other side of the client-server divide where the hardware numbers in the hundreds or thousands of units; has a low profit or more often a net cost, over it's life cycle; and where it has to compete for resources with any number of other equally important and potentially, equally memory & cycle hungry applications.

In a past life I did a good deal of usability testing on a "workstation application". The specification called for a user perceived response time of 1/10th of a second. In performance testing, this was easily achieved in the first Beta. But when that Beta was rolled out to a limited evaluation group of users, their immediate and strident verdict was "It's to slow!". Performance testing had been carried out on a standard specification workstation, memory, cpu, graphics card, disc performance, OS type and version were all identical, but still they complained.

What went wrong was that the test workstations were running nothing else. The software ran quickly because it had all the cycles and all the memory to itself. In the real world, every user had browsers, email clients, WPs and spreadsheets and at least one and often several 3270 emulators running. The net effect was that the combined memory usage pushed the machines into swapping and performance fell dramatically. The projected cost of upgrading the 10,000 machines that would run the software was huge.

The solution settled upon was to go into the application and remove several layers of abstraction at the lower levels. Essentially, lots of small items that had each been instantiated as individual objects were stored as a single, compact C array and accessed directly. The additional cost of breaking up the conglomorated items into their individual fields each time they were accessed was more than offset by the considerable reduction in memory use which avoided the need to go into swapping on most workstations.