Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>When I did some testing on my machine, I got about 60MB/s out of my not-so-modern hardware. That's 3.6GB/minute or 216GB per hour (so 3hours produces about 640GB). I would expect that the time spent in your application is mostly "waiting for the disk", in which case, it makes absolutely no difference what IO methods you use. </p> <p>But like ALL performance questions, it's not an answer you can find by asking on the internet, or look it up in a book, or whatever. It has to be measured on the system(s) that you are concerned about. Change my skanky old hard-disks for some nicely configured RAID, and you get a much better performance [if it's the right kind of raid system - some are slower than individual disks, as the intention isn't to speed up access but ensure reliability]. </p> <p>You can also make some comparisons: 1. redirect your software's output to /dev/null - check how long it takes to run your code now. If it's something like 10-100x faster than when you are writing to files, then you know that the way you write now or some other method won't make any difference at all. 2. Create similar sized files with <code>dd if=/dev/zero of=yourfile bs=4k count=largenumber</code> (largenumber * 4KB = typical file-size) - if your application is writing several files, then write a script that writes several different files like that). If that's much faster than your application, then there's something to be gained by altering the way you do output from your application.</p> <p>If either of the two things above show that there's a potential for gain, then write some benchmarks that produce a large amount of output in the same way you intend your application to work and see what makes a difference. By all means come back here and ask questions. But my guess is that your application won't run any faster or slower no matter what you do about output mechanisms, because it's all down to "how fast the disk can write". </p>
    singulars
    1. This table or related slice is empty.
    1. POfile IO performance C
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USMats Petersson
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POfile IO performance C
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COCalling `write` without carefully picking buffer sizes instead of using the standard facilities may kill I/O, and using very carefully crafted calls to `write` may increase performance by as much as .00001% (this will vary), so it's probably not correct to say it makes "absolutely no difference". Calling `write` for each byte is guaranteed to kill the performance! But all reasonable schemes will be essentially equivalent.
      singulars
      1. PO
      1. USWilliam Pursell
    2. COYes, I tend to intentionally avoid being overly pedantic in my answers, as it doesn't actually help much. The original question already mentions that there is blocks of 1KB, which should be fine - there's buffering in the OS whichever way you do it.
      singulars
      1. PO
      1. USMats Petersson
    3. COThanks for the comments guys, I think I'll have to benchmark my application to see the appropriate buffer to call write() with. And I see where @WilliamPursell is coming from, indeed for even a small amount of savings in time due to IO I'm likely not to see much improvement anyways. Thanks though!
      singulars
      1. PO
      1. USjanjust
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload