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. 
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
https://threejs.org/examples/#webgl_octree_raycasting
Iām getting low 40ās fps
https://threejs.org/examples/#webgl_performance_doublesided
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.geometry.computeFaceNormals();
simX.geometry.computeBoundingSphere();
simX.updateMatrixWorld();
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.
2 Likes
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?
copyVector3sArray:
function(a)
{
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);
b[c++]=f.x;
b[c++]=f.y;
b[c++]=f.z
}
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.