Potential jank caused by VariationsSeedStore::StoreSafeSeed() |
|
Issue descriptionWe collected slow reports from users facing janks and found that the function mentioned above is taking too much time on the main thread, potentially causing janks at startup The stack trace that was hit the most: Unknown deflate_slow Cr_z_deflate compression::GzipCompress(base::BasicStringPiece<std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char> > >, std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char> >*) variations::VariationsSeedStore::VerifyAndCompressSeedData(std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char> > const&, std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char> > const&, bool, variations::VariationsSeedStore::SeedType, std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char> >*, variations::VariationsSeed*) variations::VariationsSeedStore::StoreSafeSeed(std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char> > const&, std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char> > const&, variations::ClientFilterableState const&, base::Time) variations::SafeSeedManager::RecordSuccessfulFetch(variations::VariationsSeedStore*) variations::VariationsService::OnSimpleLoaderComplete(std::__ndk1::unique_ptr<std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char> >, std::__ndk1::default_delete<std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char> > > >) ... base::OnceCallback<void (bool)>::Run(bool) && network::(anonymous namespace)::SaveToStringBodyHandler::NotifyConsumerOfCompletion(bool) network::(anonymous namespace)::SimpleURLLoaderImpl::FinishWithResult(int) network::mojom::URLLoaderClientStubDispatch::Accept(network::mojom::URLLoaderClient*, mojo::Message*) mojo::internal::MultiplexRouter::ProcessIncomingMessage(mojo::internal::MultiplexRouter::MessageWrapper*, mojo::internal::MultiplexRouter::ClientCallBehavior, base::SequencedTaskRunner*) mojo::internal::MultiplexRouter::Accept(mojo::Message*) mojo::Connector::ReadSingleMessage(unsigned int*) mojo::Connector::ReadAllAvailableMessages() void base::internal::Invoker<base::internal::BindState<void (net::HostResolverImpl::LegacyRequestImpl::*)(int), base::internal::UnretainedWrapper<net::HostResolverImpl::LegacyRequestImpl> >, void (int)>::RunImpl<void (net::HostResolverImpl::LegacyRequestImpl::*)(int), std::__ndk1::tuple<base::internal::UnretainedWrapper<net::HostResolverImpl::LegacyRequestImpl> >, 0u>(void (net::HostResolverImpl::LegacyRequestImpl::*&&)(int), std::__ndk1::tuple<base::internal::UnretainedWrapper<net::HostResolverImpl::LegacyRequestImpl> >&&, std::__ndk1::integer_sequence<unsigned int, 0u>, int&&) base::internal::Invoker<base::internal::BindState<void (net::HostResolverImpl::LegacyRequestImpl::*)(int), base::internal::UnretainedWrapper<net::HostResolverImpl::LegacyRequestImpl> >, void (int)>::RunOnce(base::internal::BindStateBase*, int) mojo::SimpleWatcher::OnHandleReady(int, unsigned int, mojo::HandleSignalsState const&) ... base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*) base::MessageLoop::RunTask(base::PendingTask*) base::MessageLoop::DoWork() base::MessagePumpForUI::OnNonDelayedLooperCallback() base::(anonymous namespace)::NonDelayedLooperCallback(int, int, void*)
,
Oct 2
Sorry, I am currently unable to find how much jank this is causing (since the unwinding doesn't always work). This stack trace seems to be hit frequently among the samples, in top 50~ of the successful unwinds. I understand that still doesn't characterize the impact. I am still working on this part. If you think this stack trace cannot be taking too long I will try to debug what went wrong in the traces. |
|
►
Sign in to add a comment |
|
Comment 1 by asvitk...@chromium.org
, Oct 2