Hi,

Earlier today I tried to show how to use a profiler to somebody while
running a checkout on a very recent Subversion build on Windows. This build
contained Sqlite 3.8.3.1.

We happened to see that one of the functions that caught about 15% of the
profile samples was the function 'winDelete()' in the Sqlite amalgamation.

That by itself is not that surprising as we know delete is quite slow on
Windows, but what was really surprising was that about 6% of that 15% was
caused by the GetFileAttributes() call that Sqlite performs right before
calling DeleteFileW().


If I look at the relevant source code of winDelete()
[[
      attr = osGetFileAttributesW(zConverted);
#endif
      if ( attr==INVALID_FILE_ATTRIBUTES ){
        lastErrno = osGetLastError();
        if( lastErrno==ERROR_FILE_NOT_FOUND
         || lastErrno==ERROR_PATH_NOT_FOUND ){
          rc = SQLITE_IOERR_DELETE_NOENT; /* Already gone? */
        }else{
          rc = SQLITE_ERROR;
        }
        break;
      }
      if ( attr&FILE_ATTRIBUTE_DIRECTORY ){
        rc = SQLITE_ERROR; /* Files only. */
        break;
      }
      if ( osDeleteFileW(zConverted) ){
        rc = SQLITE_OK; /* Deleted OK. */
        break;
      }
]]

it appears that Sqlite only calls GetFileAttributes() to improve the error
handling; especially for trying to accidentally remove a directory.


Is it possible to improve this code by first calling osDeleteFileW() and
only if that fails falling back to looking at osGetFileAttributes() on what
to do next? (Read: error out | retry)


The DeleteFileW() function will just fail when trying to delete a directory
(with a detailed error in GetLastError()), so I don't think this should
introduce a behavior change... but a tweak like this might improve
performance in this very common code path.

Thanks,
        Bert

_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to