Skip to content
  • cblu's avatar
    Fixed: 3131714 - System becomes unresponsive while downloading · 14c28e89
    cblu authored
    	While downloading a file, Safari and the Finder take up 30%-40% of the CPU each. This is happening because for every chunk of data we write to disk, we call -[NSWorkspace noteFileSystemChanged:]. noteFileSystemChanged is inefficient. It sends 2 AppleEvents each with 60 timeouts. The event also causes the Finder to do a lot of work.
    
    	We should:
    	- Send 1 AppleEvent ourselves with no timeout since we don't care about the reply
    	- Call the notification/event less often. The only benefit of sending the event for every chunk written is that the file size updates in the Finder. Not worth the performance impact.
    
            Reviewed by kocienda.
    
            * Downloads.subproj/WebDownloadHandler.m:
            (-[WebDownloadHandler cleanUpAfterFailure]): call _web_noteFileChangedAtPath
            (-[WebDownloadHandler createFileIfNecessary]): call _web_noteFileChangedAtPath
            (-[WebDownloadHandler writeDataForkData:resourceForkData:]): don't call noteFileSystemChanged
            (-[WebDownloadHandler finishedLoading]): call _web_noteFileChangedAtPath
            * Misc.subproj/WebNSWorkspaceExtras.h: Added.
            * Misc.subproj/WebNSWorkspaceExtras.m: Added.
            (-[NSWorkspace _web_noteFileChangedAtPath:]): Notifies the Finder (or any other app that cares) that we added, removed or changed the attributes of a file. This method is better than calling noteFileSystemChanged: because noteFileSystemChanged: sends 2 apple events both with a 60 second timeout. This method returns immediately.
            * WebKit.pbproj/project.pbxproj:
    
    
    git-svn-id: http://svn.webkit.org/repository/webkit/trunk@3121 268f45cc-cd09-0410-ab3c-d52691b4dbfc
    14c28e89