[Kst] WG: Remaining bugs in 2.0.5

Brisset, Nicolas Nicolas.Brisset at eurocopter.com
Fri Jul 6 14:27:37 UTC 2012

I think its probably intrinsic to the design of the plugin.  It reads in all of the file (for the lines being read) and changing that would kill performance in other cases.  It should not be changed for 2.0.6

Ok for not changing it for Kst 2.0.6. But regarding the design of the plugin, there used to be a time when it would just parse the file incrementally, store the offsets to each new line (i.e. sample set), and then use that info to fseek() into the right place to read the data. If we don't close the file between each readField() maybe performance is still OK.

The other option could be to add a checkbox in the ASCII config like "Cache data to RAM", in which case we'd keep the data in RAM to avoid slow file operations. But for big files as said it can become an issue, so having this option would be nice, provided that reading from file is fast enough.

The next question if we store to RAM is that storing the complete ASCII file could be bigger that storing all the double values (depending on the format), which does not make too much sense. I don't know how much turning each string to a double would cost in terms of performance (atof() seems to be slow) but having all the data in a double matrix in RAM would make it even faster.

We can discuss all that again when we start 2.0.7...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kst/attachments/20120706/8502ae2a/attachment.html>

More information about the Kst mailing list