octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #51871] loading '-ascii' format files is slow


From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #51871] loading '-ascii' format files is slow
Date: Wed, 8 Nov 2017 17:31:43 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0

Follow-up Comment #35, bug #51871 (project octave):

I guess somewhere in that getline_alleol() would need to be a clearing of the
string str, but I'm wondering if we could avoid the clearing of the string str
and instead reuse it's current contents until it is necessary to expand it. 
Say something like below.  The idea is to overwrite the existing buffer until
it is necessary to expand it.  Then, at the end of the current line I've put a
0x0D EOL character in place so that subsequent routines which extract floating
point data will end at the EOL.  That's the general idea.  I wonder if that
would be more efficient than clearing the string buffer and continually using
push_pack to expand it.


istream& getline_alleol (istream& is, string& str) {
    int c;
    int i;
    int strsize = str.size();

    for (i=0; i < strsize; i++) {
        c = is.get ();
        if (c == EOF || c == 0x0A)
            break;
        elseif (c == 0x0D) {
            if ((c = is.peek ()) != EOF) {
                 if (c == 0x0A)
                     is.ignore ();
            }
            break;
        } else
            str.replace (i,  1,  &c);
    }

    if (i == strsize) {
        while ((c = is.get ()) != EOF) {
            if (c == 0x0A)
                break;
            elseif (c == 0x0D) {
                if ((c = is.peek ()) != EOF) {
                    if (c == 0x0A)
                         is.ignore ();
                }
                break;
            } else
                str.push_back(c);
        }
       str.push_back (i,  1, 1, 0x0D);
    } else
       str.replace (i,  1, 1, 0x0D);

    return is;
}



    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?51871>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]