Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

High CPU load in Safari #46

Open
Astro-mh opened this issue Jan 8, 2020 · 7 comments
Open

High CPU load in Safari #46

Astro-mh opened this issue Jan 8, 2020 · 7 comments

Comments

@Astro-mh
Copy link

Astro-mh commented Jan 8, 2020

When running in JupyterLab in Safari the latest fastprogress has a very high CPU load, up to 100% on a relatively modern machine.

Profiling shows that Safari is spending almost all its time in loops of WebCore::Document::updateStyleIfNeeded. CPU load returns to normal if I remove everything from the <style> block of html_progress_bar, but then, of course, I get a generic progress bar style rather than one like that shown in the README.

@sgugger
Copy link
Contributor

sgugger commented Jan 8, 2020

Could elaborate on that? What is the generator you are wrapping inside a progress bar? And is this only happening on Safari/jupyter lab or also on other navigators/jupyter notebook?
Also, does the change result in a significantly faster progress bar?

@Astro-mh
Copy link
Author

Astro-mh commented Jan 8, 2020

For testing I'm using the code from the Usage section of the README (the first one, with the update_graph commented out). This is only on Safari, Firefox and Chrome don't show the same behaviour. The speed of the progress bar doesn't appear change, but at high CPU load the whole notebook becomes jittery, trying to scroll can take several seconds.

I've now found that by moving border: none; and background-size: auto; to the inline style of the <progress> tag I get the proper style and have low CPU load, but that's still missing the progress-bar-interrupted definition, and any other pseudo-elements.

@rfrelow83
Copy link

I'm seeing the same thing. When the fastprogress bar comes up, the Safari browser spikes to around 100% cpu, and I'm unable to scroll. This does not happen on Firefox or Brave (based on Chromium).

The workaround mentioned by @Astro-mh didn't help. I made those changes locally in ~/.local/lib/python3.6/site-packages/fastprogress/core.py, and restarted the notebook kernel, not sure if I missed a step.

@essandess
Copy link

I believe this issue causes PyMC3’s .sample method to break on Safari and a Jupyter notebook.

This MWE causes high CPU and energy usage when run in Safari. There is an intermittent Safari error message in the Jupyter Notebook tab that says:

This web page has been reloaded because it was using significant energy

Reloading the web page during MCMC sampling causes the Python processes to stall.

This MWE code works fine in Chrome because Chrome doesn’t have this issue. Possibly related issues:

MWE modified from https://github.com/CamDavidsonPilon/Probabilistic-Programming-and-Bayesian-Methods-for-Hackers/blob/master/Chapter3_MCMC/Ch3_IntroMCMC_PyMC3.ipynb

import numpy as np, pymc3 as pm, theano.tensor as tt

data = np.loadtxt("Chapter3_MCMC/data/mixture_data.csv", delimiter=",")

with pm.Model() as model:
    p1 = pm.Uniform('p', 0, 1)
    p2 = 1 - p1
    p = tt.stack([p1, p2])
    assignment = pm.Categorical("assignment", p, 
                                shape=data.shape[0],
                                testval=np.random.randint(0, 2, data.shape[0]))
with model:
    sds = pm.Uniform("sds", 0, 100, shape=2)
    centers = pm.Normal("centers", 
                        mu=np.array([120, 190]), 
                        sd=np.array([10, 10]), 
                        shape=2)
    
    center_i = pm.Deterministic('center_i', centers[assignment])
    sd_i = pm.Deterministic('sd_i', sds[assignment])
    
    # and to combine it with the observations:
    observations = pm.Normal("obs", mu=center_i, sd=sd_i, observed=data)

with model:
    step1 = pm.Metropolis(vars=[p, sds, centers])
    step2 = pm.CategoricalGibbsMetropolis(vars=[assignment])
    trace = pm.sample(25000, step=[step1, step2])
    
with model:
    trace = pm.sample(50000, step=[step1, step2], trace=trace)

@jpc
Copy link
Contributor

jpc commented Apr 7, 2021

Hi,

My Apple M1 CPU would stay at 100% during training and Safari would kill the tab (breaking training) as soon as the computer becomes idle (or I switch to a new tab). This makes fastai almost unusable on Safari, especially in JupyterLab with bigger notebooks.

I managed the figure out the reason for this issue and fix it. Please see #79 for the pull request.

@gkossakowski
Copy link

I experience the same problem, checking if #79 fixes it for me locally.

@jpc
Copy link
Contributor

jpc commented Dec 29, 2021

Hi @sgugger @jph00,

sorry to ping you like that but it's been > half a year and I am afraid #79 has fallen through the cracks. What would be needed to release a new version of fastprogress so fresh installs of fastai won't have this bug?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants