New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 891488 link

Starred by 1 user

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug



Sign in to add a comment

Potential jank caused by VariationsSeedStore::StoreSafeSeed()

Project Member Reported by ssid@chromium.org, Oct 2

Issue description

We 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*)
 
How much jank?

This should just be gzipping ~20k string in memory and I'd be surprised that this should take a long time, unless there's something else at play (e.g. something injected into the processes that's hooking into gzip code).
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