Currently, g_file_set_contents() calls fsync() before calling rename().  We do this to ensure that the new data has actually made it to disk before we replace the old file.

On btrfs, we don't need to do that (as implemented on Linux, at least).

(quoting here for permanence)

"""
   What are the crash guarantees of overwrite-by-rename?

   Overwriting an existing file using a rename is atomic. That means that
   either the old content of the file is there or the new content. A
   sequence like this:

     echo "oldcontent" > file

     # make sure oldcontent is on disk
     sync

     echo "newcontent" > file.tmp
     mv -f file.tmp file

     # *crash*

   Will give either

    1. file contains "newcontent"; file.tmp does not exist

    2. file contains "oldcontent"; file.tmp may contain "newcontent", be
       zero-length or not exists at all.
"""

https://btrfs.wiki.kernel.org/index.php/FAQ#What_are_the_crash_guarantees_of_overwrite-by-rename.3F

I've done a bit of experimentation that indicates exactly what you'd probably expect: skipping the fsync() is a huge performance win.

On my system, this program:

"""
   #include <glib.h>

   int
   main (void)
   {
     gint i;

     for (i = 0; i < 1000; i++)
       {
         gchar buffer[10];

         g_sprintf (buffer, "%d", i);
         g_file_set_contents ("myfile", buffer, -1, NULL);
       }

     return 0;
   }
"""

goes from 48 seconds to 0.3 seconds.

Another case: dconf currently completely replaces the database on every write and does so using g_file_set_contents().  Not calling fsync() reduces the time taken to do 1 dconf write from 64 milliseconds to 3.5ms, round trip.