Chrome: Performance after latest update?

Any body notice issues with the latest google chrome update?

No. Please elaborate.

Well, for this game I’m making I used to be able to update a single geometry made up of around 70000 vertices each frame with no performance issues. Now I can only only update 7000. Big difference. Google warned that their newest update would drag performance because of all the security holes they’ve been patching. My project has been directly affected. :confused:

I just checked out Rome, seems to have become choppy on my computer. Anyone else experiencing any performance slow downs with Chrome?

Nope. You might want to file a bug right here if you think the performance problem is related to the Chrome update:

@Awoken create a live example using Codepen that demonstrates the change in performance and we’ll help you to test it.

How about this three.js example here

I’m getting low 40’s fps
30 fps

What’s your graphics card? And did you test those examples with the previous version of chrome to see if you get a different fps?

Admittedly no, but previously I had few problems with performance. Especially with Three.js
I have a 550m nvidia graphics card for a ROG Asus laptop. 3Gigs of video RAM. Older. However; I used to be able to run my content and it would easily display at 60 fps, now with the latest update I’m down to ~9 fps.

I remember bringing up this issue with everyone before. Previously, after the content was loaded and running for about 30 seconds the performance would drop significantly. I’d just refresh the page and that was a quick easy fix because the problem wouldn’t come back. Now the problem persists out of the gate.

The bottle neck is the following, after commenting them all out the performance shot back up again. So I know it’s not my function calculating all the matrix updates for each vertices.

simX.geometry.verticesNeedUpdate = true;
simX.geometry.facesNeedUpdate = true;
simX.geometry.normalsNeedUpdate = true;
simX.visible = true;

Those used to run each frame with no problems.

Ouch, is that THREE.Geometry?

1 Like

Yes, within a Mesh

It might be some memory issue especially when it raises over time. I’m not sure right now but doesn’t THREE reallocates the buffer attributes each time to copy the object values when using THREE.Geometry? I would recommend using BufferGeometry anyway, for per-frame updates especially.

But if I remember correctly buffer geometry is better suited to static shapes that need only be loaded once. This is a dynamic shape whose vertices are always changing. Either way, there has been a major performance loss in the past 24 hrs. For me.

THEE.Geometry is THREE.BufferGeometry, before it is rendered it’s converted to a BufferGeometry. THREE.Geometry is just an easier interface for creating geometries, since you don’t need to deal with offsets and buffers. If you know a maximum size you could preallocate it for this, so you won’t allocate a lot memory each time.

Could you test the examples you posted with an earlier build of chrome to see if and what’s the difference?

But if I remember correctly buffer geometry is better suited to static shapes that need only be loaded once.

I think there was a note in the docs saying something like this at one point. I’m not sure if it was ever true, but I’m sure it’s not true now.


I guess Google made some changes to Chrome to help thwart the vulnerabilities of Spector and meltdown. They decided to chop the processes up into smaller chunks so as to make it more difficult to execute such an attack.

So I installed the previous version of Chrome and here is the performance. Exact same code


Hmmmm… I’m not sure what to do. This seems to be out of my hands. I wouldn’t even know how to report this to Google seeing as I’m not sure where the issue lies.

It rather was the precision of the timers and shared buffers. At least i didn’t noticed a major performance hit and i have some really demanding critical things. You should make a memory allocation record too. According too the memory track on your screencap it definetly allocates a lot.

As mentioned i’d suggest to move away from the abstracted geometry class anyway. How is this sphere/planet updated each time, what exactly changes per frame? If you need a non-fixed dynamic buffer i might have a solution, since i’ve implemented exactly that for THREE.

the planet isn’t updated. it’s static and rarely updates. Only when the user manually edits the terrain. What updates are visual representations of people moving about the planet. All the people are clumped into a single Mesh and then to simulate their movement I just update the positions of their respective vertices along their lines of travel.

This program demands a lot of memory because the whole planet is one big physics object. I’m keeping track of everything because I want to simulate a world of people.

This seems to be the function that is causing the bottle neck.
Are you all saying that I could directly change the buffered geometries vertices and that this problem would go away?



for(var b=this.array,c=0,d=0,e=a.length;d<e;d++)


var f=a[d];

void 0===f&&(console.warn(“THREE.BufferAttribute.copyVector3sArray(): vector is undefined”,d),f=new n);





return this


I thought that the buffer geometry ‘loaded’ the geometry into memory and there for didn’t need to be touched. I guess I’m just unsure what benefit I would get from changing it over to just a buffer geometry.