Please follow the instructions here: https://www.chromium.org/developers/how-tos/submitting-a-performance-bug

to provide more information. 

Here's the trace file

Deleted: trace_clearcacheperfbug.json.gz 3.6 MB

trace_clearcacheperfbug.json.gz 3.6 MB Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

eric@ Thanks for the issue.

Able to reproduce this issue on Mac OS 10.13.3 on the on the latest Canary 67.0.3376.0 and Stable 65.0.3325.162 by following the steps given above.
This issue is only observed on MacBook Air. Cannot observe the issue on MacBook Pro, Windows 10 and Ubuntu 14.04.

Can observe that the on hitting the Clear Browsing Data button, it is taking ~10 seconds even if there isn't data.
Attached is the screen cast for reference.

This is a Non-Regression issue as this behavior is observed from M60 Chrome builds.
Hence marking this as Untriaged for further updates from Dev.

Thanks..

Deleted: 823746.mp4 1.7 MB

	823746.mp4 1.7 MB View Download

Mac triage: marking for Profiles triage.

Not seeing very much contention in the trace. This suggests perhaps a logic bug with some type of timed wait in md settings.

Given that this issue appears to be reproducible on certain machines/configurations, seems like enough for the MD team to take a look. Over to groby to find an owner.

It's probably all MACs....mine is a Pro laptop MacBook Pro (15-inch, 2016)

This is pretty easy to repro if you have a cache of a decent size (mine is 253 MB). Taking two samples in Activity Monitor, the issue seems to be in the disk cache:

    1294 Thread_7648909: TaskSchedulerForegroundBlockingWorker
    + 1294 thread_start  (in libsystem_pthread.dylib) + 13  [0x7fff5db6fc5d]
    +   1294 _pthread_start  (in libsystem_pthread.dylib) + 377  [0x7fff5db7056d]
    +     1294 _pthread_body  (in libsystem_pthread.dylib) + 340  [0x7fff5db706c1]
    +       1294 base::(anonymous namespace)::ThreadFunc(void*)  (in Google Chrome Framework)  load address 0x109e87000 + 0x215dbb7  [platform_thread_posix.cc:78]
    +         1294 base::internal::SchedulerWorker::Thread::ThreadMain()  (in Google Chrome Framework)  load address 0x109e87000 + 0x214b679  [type_traits:4644]
    +           1294 base::internal::TaskTracker::RunAndPopNextTask(scoped_refptr<base::internal::Sequence>, base::internal::CanScheduleSequenceObserver*)  (in Google Chrome Framework)  load address 0x109e87000 + 0x2150fe5  [task_tracker.cc:353]
    +             1294 base::internal::TaskTrackerPosix::RunOrSkipTask(base::internal::Task, base::internal::Sequence*, bool)  (in Google Chrome Framework)  load address 0x109e87000 + 0x21526e3  [task_tracker_posix.cc:25]
    +               1294 base::internal::TaskTracker::RunOrSkipTask(base::internal::Task, base::internal::Sequence*, bool)  (in Google Chrome Framework)  load address 0x109e87000 + 0x2151672  [trace_event.h:1106]
    +                 1294 base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*)  (in Google Chrome Framework)  load address 0x109e87000 + 0x20e3b88  [callback_forward.h:11]
    +                   1294 base::(anonymous namespace)::PostTaskAndReplyRelay::RunTaskAndPostReply()  (in Google Chrome Framework)  load address 0x109e87000 + 0x215dd79  [callback_forward.h:11]
    +                     1294 base::internal::Invoker<base::internal::BindState<void (*)(base::OnceCallback<int ()>, int*), base::OnceCallback<int ()>, int*>, void ()>::RunOnce(base::internal::BindStateBase*)  (in Google Chrome Framework)  load address 0x109e87000 + 0x64b21b  [callback_forward.h:11]
    +                       1294 void base::internal::ReturnAsParamAdapter<int>(base::OnceCallback<int ()>, int*)  (in Google Chrome Framework)  load address 0x109e87000 + 0x64b196  [callback.h:95]
    +                         1294 disk_cache::SimpleSynchronousEntry::DeleteEntrySetFiles(std::__1::vector<unsigned long long, std::__1::allocator<unsigned long long> > const*, base::FilePath const&)  (in Google Chrome Framework)  load address 0x109e87000 + 0x2527cab  [algorithm:1264]
    +                           1292 disk_cache::SimpleSynchronousEntry::DeleteFilesForEntryHash(base::FilePath const&, unsigned long long)  (in Google Chrome Framework)  load address 0x109e87000 + 0x252798a  [simple_synchronous_entry.cc:1562]
    +                           ! 1292 disk_cache::SimpleSynchronousEntry::DeleteFileForEntryHash(base::FilePath const&, unsigned long long, int)  (in Google Chrome Framework)  load address 0x109e87000 + 0x252bbfa  [simple_synchronous_entry.cc:1553]
    +                           !   1291 base::DeleteFile(base::FilePath const&, bool)  (in Google Chrome Framework)  load address 0x109e87000 + 0x20f1804  [file_util_posix.cc:393]
    +                           !   : 1291 unlink  (in libsystem_kernel.dylib) + 11  [0x7fff5da32154]
    +                           !   :   1291 __unlink  (in libsystem_kernel.dylib) + 10  [0x7fff5da3547a]
    +                           !   1 base::DeleteFile(base::FilePath const&, bool)  (in Google Chrome Framework)  load address 0x109e87000 + 0x20f1735  [file_util_posix.cc:388]
    +                           !     1 lstat$INODE64  (in libsystem_kernel.dylib) + 10  [0x7fff5da35fca]
    +                           1 disk_cache::SimpleSynchronousEntry::DeleteFilesForEntryHash(base::FilePath const&, unsigned long long)  (in Google Chrome Framework)  load address 0x109e87000 + 0x25279b1  [simple_synchronous_entry.cc:1562]
    +                           ! 1 disk_cache::SimpleSynchronousEntry::DeleteFileForEntryHash(base::FilePath const&, unsigned long long, int)  (in Google Chrome Framework)  load address 0x109e87000 + 0x252bbfa  [simple_synchronous_entry.cc:1553]
    +                           !   1 base::DeleteFile(base::FilePath const&, bool)  (in Google Chrome Framework)  load address 0x109e87000 + 0x20f1735  [file_util_posix.cc:388]
    +                           !     1 lstat$INODE64  (in libsystem_kernel.dylib) + 10  [0x7fff5da35fca]
    +                           1 disk_cache::SimpleSynchronousEntry::DeleteFilesForEntryHash(base::FilePath const&, unsigned long long)  (in Google Chrome Framework)  load address 0x109e87000 + 0x2527a21  [simple_synchronous_entry.cc:1569]
    +                             1 base::DeleteFile(base::FilePath const&, bool)  (in Google Chrome Framework)  load address 0x109e87000 + 0x20f1735  [file_util_posix.cc:388]
    +                               1 lstat$INODE64  (in libsystem_kernel.dylib) + 10  [0x7fff5da35fca]

Deleted: bug-823746-1.txt 242 KB

bug-823746-1.txt 242 KB View Download

Deleted: bug-823746-2.txt 264 KB

bug-823746-2.txt 264 KB View Download

Note that the original report was on stable, that wouldn't be using SimpleCache on a Mac.

--Chrome Identity automated triaging--

This bug is Assigned and has gone one month without any activity, so it is being moved to Available to indicate that it is not actively being worked on. If you are working on this bug, please mark yourself as the owner and move back to Assigned. Please see https://goo.gl/78kbny for more details. Please remove the Services>SignIn or UI>Browser>Profiles components if this bug isn't related to Chrome Identity.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

--Chrome Identity automated triaging--

This bug is Assigned and has gone one month without any activity, so it is being moved to Available to indicate that it is not actively being worked on. If you are working on this bug, please mark yourself as the owner and move back to Assigned. Please see https://goo.gl/78kbny for more details. Please remove the Services>SignIn or UI>Browser>Profiles components if this bug isn't related to Chrome Identity.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Given that M60 happened a while ago - is this still reproducible?

Let's ask TE to see if they can still repro this.

Able to reproduced this issue on Mac OS 10.13.6 on the latest Stable 71.0.3578.98 as per comment #6.

Can observe that the on hitting the Clear Browsing Data button in chrome://settings, it is taking ~10 seconds on a new chrome profile.
Attached is the screen cast for reference.

Hence removing 'Needs-TestConfirmation' label and requesting Dev to look into the issue.

Thanks..

++ screencast

Deleted: 823746-M71.mp4 1.8 MB

	823746-M71.mp4 1.8 MB View Download

TE: do you happen to have a 10.14 machine available? If so, can you test this on 10.14 as well?

Able to reproduce this issue on Mac OS 10.14 on the latest Stable 71.0.3578.98 as well.
Attached is the screen cast for reference.

Hence removing 'Needs-TestConfirmation' label and requesting Dev to look into the issue.

Thanks..

Deleted: 823746-mojave.mp4 1.7 MB

	823746-mojave.mp4 1.7 MB View Download

Alright, thanks. I wonder why I can't reproduce this...

Maybe your cache isn't large enough, or you're on all-SSD? I got a sample in #10.