What do you mean 'fetching trends from a .csv file' ?
If that is a new feature in InTouch, forgive that I am unaware of it.
Generally, InTouch historical trending information is stored in a proprietary format, which can be exported to .csv files. Later versions of InTouch (I'm thinking 8.0 and above) can also use a SQL Database as a historian, which shouldn't be slow.
If you are trying to retrieve many pens, for a long time period (8/16/24 hours or more), then the trend control (either Built-in, or the Archestra Historian) have to do a great deal of processing to render them.
I suppose the first place I'd look, is your historical logging configuration. If you have a minimum sample period set to 0.001 seconds (yes, unrealistic, I know), you are recording a boatload of data that really isn't changing in any way that can be meaningfully captured by InTouch. Same goes for if you are monitoring, oh, say, Temperature. If you are concerned with normal industrial process temperatures, the 'logging deadband' should probably be set no lower than 0.5 degrees. If the logging deadband is set to 0.01 degrees, again, you are recording virtually meaningless information. -- Well, that depends, if, in the temperature example, your nominal operating range is from 0 to 10 degrees C, then perhaps recording 0.01 degree differences might be justified.
I normally set my logging deadbands to be one half of the smallest logged increment I'm interested in. As in, if my process variable span is 0 to 400 degrees, and I'm only interested in whole degrees, my logging deadband is 0.5 degrees. If the PV is 0 to 10 Newtons, and I want resolution to 0.1 Newtons, my logging deadband is 0.05 Newtons.
The InTouch default deadband of 0 means absolutely any change in a tag will be logged. Since, by default, InTouch only logs things that change from one update to the next by more than the default, a default deadband of 0 will force it to update the log virtually every OPC/DDE/DAServer read (which also has the side-effect of making your logs dependent on the scan time of your communications servers.
How does this make retrieving a historical trend slow? The trend display must interpolate every single transition, and then decide which ones should actually be displayed. Even with a decent graphics card and monitor, and HMI running at even 1920x1280 pixels can only display a maximum of 1920 points. If you are trying to read a constantly updated historical file that has 6,292,891 data records for a given time period, the trend display is responsible for either intelligently querying the data file for every 3,277'th point (which it does NOT) or, reading in all information, including timestamps, for every single point, and interpolating the results to fit in your 1920 pixel width display.