<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.E-MailFormatvorlage18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="DE" link="blue" vlink="purple">
<div class="WordSection1">
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<p><span lang="EN-US">I think its probably intrinsic to the design of the plugin.
</span>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<o:p></o:p></p>
<p><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.
<o:p></o:p></span></p>
<p><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.
<o:p></o:p></span></p>
<p><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.<o:p></o:p></span></p>
<p><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">We can discuss all that again when we start 2.0.7…<o:p></o:p></span></p>
<p><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Nicolas<o:p></o:p></span></p>
</div>
</div>
</body>
</html>