Is this the library you are talking about?
No. That is for graphic lcds.
You want the hd44780 library package here:
If you search the forum, you can find quite a few of my posts about it.
It can quickly and easily be installed using the IDE library manager.
The i/o class you will want is hd44780_I2Cexp
Run the diag sketch (I2CexpDiag) first to make sure it is working with your h/w and that your i2c signals are properly terminated.
Then you can run the LCDispeed sketches to see the performance and get the byte timing numbers.
It has example sketches that run the i2c bus in 100kbit mode (the default) and also in 400kbit mode.
hd44780 is quite a bit faster than fm's library and if you jump to 400kbit clocking (which is beyond spec for the PCF8574 but should work on the newer parts) it is even faster.
If I remember correctly 400k mode is faster than using the IDE LiquidCrystal library with direct pin control.
The PCF8574 style of I2C LCD adapter requires 5 bytes per LCD command / data operation. There is little point in sending a block of characters. I doubt if it is much faster than one chacter at a time.
Actually, the number of bytes per i2c bytes per lcd command/data operation can vary quite a bit depending on how the author wrote the code.
The worst i2c LCD libraries are those from adafruit which send multiple bytes for every single signal on the LCD since they are treating the i/o expander port interface as a pseudo digitalWrite()/digitalRead() interface.
They are REALLY slow.
My hd44780 library is more efficient than others.
When sending a byte to the LCD, most libraries use multiple transactions, and most also use 3 bytes per nibble.
My library uses a single transaction and sends 2 i2c bytes per nibble.
Most libraries like fm's send 2 * (i2cSTART + i2cADDRbyte, + 3 + i2cEND)
I send i2cSTART + i2cADDRbyte + 2 * (2 ) + I2cEND
My library avoids an extra i2cSTART, i2cADDRbyte, i2cEND and 2 extra bytes for every single character printed.
Transferring more bytes per i2c transaction can help as the over i2c overhead is reduced START and STOP times plus the i2c address byte for i2c increase the overhead and if they can be avoided, it can help.
Unfortunately, the print() interface in Arduino is single character to the lower layers, so it isn't possible to use print() to send multiple characters to the lower library to try to speed transfers to the display.
The Print class will simply hand them 1 at a time to the h/w i/o library using the write() interface.
Another thing that hd44780 does to improve performance is handling the hd44780 LCD command execution timing in a much smarter way.
This allows the Arduino to run in parallel with the LCD.
So while every other library does a blind/dumb delay to wait for a command to complete, hd4480 will only wait if necessary.
This allows the things like CPU overhead and i2c transfer time to reduce any needed command execution delay all the way down to zero if those other overheads were longer than the LCD command execution.
Another thing that can speed things up is smaller/stronger pullups.
While it is just a small amount, if the pullups are stronger (smaller resistor value), the signals rise faster.
This will cause the i2c h/w in the AVR to run just a tiny bit faster as rise time will be shorter and the chip will see bus signals just a tiny bit faster.
Normally, this isn't something I'd ever want to deal with or count on as it such a small factor.
A bigger factor is to run the bus at 400khz rather than the default 100khz if possible