From: ootiib@hot.ee   
      
   On Thursday, 31 January 2013 20:43:30 UTC+2, Edward Rosten  wrote:   
   > On Wed, 30 Jan 2013 21:39:57 -0800, Öö Tiib wrote:   
   > > On Tuesday, 29 January 2013 05:05:08 UTC+2, fmatthew5876  wrote:   
   > >> > On my system write(2) writes 10,000,000 floats in 0.7 seconds. printf   
   > >> > requires 6 seconds, and operator<< 9 seconds.   
   > >>   
   > >> You'll have to show how you performed this test first. If you just did   
   > >> cout << f;   
   > >> or   
   > >> printf("%f", f);   
   > >>   
   > >> 10,000,000 times then it doesn't invalidate my point about function   
   > >> calls and locks.   
   > >   
   > > What point of locks?   
   >   
   > Being facetious: so that output doesn't get unpleasantly interleaved.   
      
   Ok, it was unexpected to me that someone might want to write to   
   same file from multiple threads with zero attempts to orchestrate   
   that process. Locks? Are locks right tool to manage structure of file   
   or to organize human interface? I consider any interface to be worth   
   slightly more care than just fighting such outright race conditions   
   and interleaving.   
      
   > > The text formats work also fine between applications when the amount   
   > > communicated is low. Then it does not really matter if you first   
   > > boost::format and then << to stream. It is not bottle-neck so it does   
   > > not affect overall performance how efficient that operation is.   
   > >   
   > > [...]   
   > >   
   > > Whenever you see ini, json or xml (or what not) text file that is   
   > > hundreds of megabytes large then that is trying take place of binary   
   > > formats and databases. Human, who opens it can't handle it anyway   
   > > unaided. Software that opens it is doomed to perform 10 times worse than   
   > > when using some structured binary format or database. So lose-lose-lose   
   > > situation.   
   > >   
   > > Such nonsense can only work because our users are without choice and so   
   > > have to be patient.   
   >   
   > I regularly deal with quite large data files stored as text. They are   
   > usually formatted flat text, not ini, JSON or XML, but I think the point   
   > still stands. Data files have to get very large before it's worth going   
   > to binary files. Text based files are much easier to debug (you can open   
   > fragments of it in an editor) and are much more interoperable. If you   
   > have a custom binary format of some sort then that very much limits the   
   > tools that you can process it with.   
      
   100Mb text file is "easier to debug" than a SQL database of same size?   
   That amount of data is comparable with text in hundreds of books. I read   
   about 2-3 books/week so it would take me couple years to read it.   
   Without proper tools I am lost there. For database there are most tools   
   one can dream of ... often even integrated into IDEs.   
      
   > This is the case where programmer time is important, and text files   
   > generally save a lot of it. Programmer time is always important: it gives   
   > the users the choice between being patient for the software to finish and   
   > not having any software at all.   
      
   The stories that text is always simpler and faster to handle do perhaps   
   sell well to some pointy-haired boss. In reality the guys who screw with   
   spagetthi that inputs/outputs/modifies yet-another text format work at   
   least 4 times longer time on it than others who use some database engine   
   for same goal. The results performance loses about 10:1.   
      
   If performance of iostream starts to feel then usage of text format is   
   most likely *the actual problem*.   
      
      
   --   
         [ See http://www.gotw.ca/resources/clcm.htm for info about ]   
         [ comp.lang.c++.moderated.    First time posters: Do this! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)