i using qfile file reader , file writer copy files usb inside application. have been trying figure out why file copies usb (with progress bar) taking long. found out when close qfile object used writing, close() operation can take on time taken actual write operation. these large files, , read/write blocks of 16384 bytes, , send signal gui increase progress bar viewed user. ended adding call flush() after each write since assume result of out stream not having yet been written disk. didn't make difference. close of outgoing qfile object still takes longer seems have been write time (timing taken before , after copy, , before , after each of qfile::close() calls, timing code has been removed ease of reading, debugged , saw happening). of course, doesn't not call close() function, since destruction of qfile object causes called.
my code follows (minus error checking, destination space checking, etc):
void filecopy::run() { qbytearray bytes; int totalbyteswritten = 0; int inlistsize = inlist.size(); (int i=0; !canceled && i<inlistsize; i++) { qstring inpath = inlist.at(i).inpath; qstring outpath = inlist.at(i).outpath; qfile infile(inpath); qfile outfile(outpath); int filesize = infile.size(); int byteswritten = 0; if (!infile.open(qiodevice::readonly)) { return; } if (!outfile.open(qiodevice::writeonly)) { infile.close(); return; } // copy fcs file progress while (!canceled && byteswritten < filesize) { bytes = infile.read(maxbytes); qint64 outsize = outfile.write(bytes); outfile.flush(); if (outsize != bytes.size()) { break; } byteswritten += outsize; totalbyteswritten += outsize; q_emit signalbytescopied(totalbyteswritten, i+1, inlistsize); qthread::usleep(100); // allow time detecting cancel } infile.close(); outfile.close(); } // other error checking done here }
can see way passed this? prefer progress bar move more slowly, more accurately displaying state of copy user, have progress bar read 100% in less half time takes copy , close complete.
i have tried using qsavefile instead of qfile output, qsavefile::commit() has same exact problem, taking more time commit finish actual copy loop. assume because, underneath, using same functionality qfile is, derived qiodevice.
i have considered moving using standard streams, keep consistency in how file handling done in application. possibility though, if qfile::close() going take long close. or possible standard stream have same issue?
i working on win7 32-bit box vs2010 using qt5.1.1 , qt 1.2.2 vs add-in. suggestions.
while writing, os caches writes in memory (fast). when close file has flush data disk (slow - if has not written any of yet). closing file has wait os putting data onto disk (usb) , may of @ time.
the reason why operating systems of course speed writes - , can away flushing data disk in background when nothing else going on (so don't notice actual cost, since amortized on time nothing else going on). if write , close @ once going notice. note: alternative write calls being slower - still end spending same actual time.
Comments
Post a Comment