Are Spheres Faster than IndexedFaceSets?

Because I did low level programming in DirectX 3D before i ever new about vrml It never entered my mind that there would be any difference in the speed between a Sphere node and a IndexedFaceSet node in vrml. The reason I thought this was because when I programmed in DirextX there was no such thing as a function that would render a sphere only functions to render triangles. So it seemed only natural to assume that any shape that was more complex than a triangle had to be at some stage broken down into triangles. Also your hear of video card performance being measured in triangles per second. If you press F7 in contact to see the performance info displayed at the bottom of your browser in the message bar you will see readouts of triangles regardless of what the shape is, be it a IndexedFaceSet or just a single Sphere. Later I have wondered of the possibilities of the vrml 3d engine some how being able to take advantage of triangles being arranged in special case patterns such as spheres but I thought if this was the case I did not think there would be much to be gained.
sphere.wrl is a sphere with a 1 meter radius using a standard built in Sphere node
TriangleSphere.wrl is identical but made out of only triangles, it is made with the same amount of flat faces (6 times 12 flat faces).
When I press F7 I get 164 triangles for sphere.wrl. but the odd thing is I get 137 triangles for TriangleSphere.wrl !
Amazing! more triangles in a sphere node! and the quality is exactly the same. I hoped to prove that there should be no guilt felt when using IndexedFaceSets and hoped that my findings would show there was no difference in rendering performance but I never expected IndexedFaceSet to actually have less triangles and be faster to render!!!
to test the speed further I wrote two more tests

sphereSpeedTest.wrl  generates 400 spheres made out of Sphere nodes. For it I get:

6.65 fps 457 primitives 65828 triangles

triangleSphereSpeedTest.wrl  generates 400 spheres made out of  IndexedFaceSet nodes. For it I get:

9.05 fps 457 primitives 54857 triangles

You can spend good amounts of money on hardware to get this sort of speed difference. Downloads may well be faster when using sphere nodes but after the download you only reap a loss in render speed if using Spheres in place of IndexedFaceSets.
Could there be more to this? maybe it depends on the hardware? or version of software? or driver? perhaps its old code in the 3d engine that use to be more efficient maybe not for rendering speed but memory efficiency. If this is the case I would think this would be now a out dated value, as now memory is so cheap.
I have all my code here open for anyone to verify my findings

What about 4 Sided Polygons?
QuadogonSphere.wrl is the same as TriangleSphere.wrl except the triangles that share two vertices and share the same plane angle are replaced with one 4 sided polygon making it look exactly the same as a Sphere node in wire frame mode. Having fewer polygons reduces the file from 1039 bytes to 983 bytes (gziped). Not much of a difference here but the difference would be greater if no normals were used and or if the 2 shapes being compared both had more polygons. This is because when we increase the number of coordinate points our coordIndex numbers increase their digit count.

quadogonSphereSpeedTest.wrl is the same as triangleSphereSpeedTest.wrl except the spheres contain 4 sided polygons. When I press F7 contact displays the same number of triangles to when the spheres were made out of 100% triangles. Its hard to be sure here if there is any speed difference between the 2 indexedFaceSet tests. I wondered if the quadogonSphereSpeedTest.wrl on average got slightly less frames per second but if there is any difference its very little.
In this test we don't see triangles gain much if anything over 4 sided polygons but it at least confirms what I thought should be the case that no render speed is gained by converting triangles to 4 sided polygons.

Speeding Things Up Using Matrices
To my understanding vrml transform nodes have to keep being set up or at least watched by the 3d engine because all transform nodes can be potentially animated. Since setting up transform nodes are expensive on CPU processing power this is wasteful for objects that never need to be animated. One theoretical solution is to make each object in an IndexedFaceSet and position the coordinates where they are wanted globally so as to avoid any need for Transformations. This would in practice probably be awkward to do and could result in huge amounts of download time because there would be no downloaded data ever reused to make other objects. The solution here is to use the vrmlscript VrmlMatrix class to transform all your objects to where they are wanted just like you would when using a Transform node but the difference is its only done once when the world initializes

triangleSphereMatrixSpeedTest.wrl is an example of using matrices to transform the each one of the 400 spheres to their targeted locations. In this example i get disappointingly no better results than i did with the triangleSphereSpeedTest.wrl example which uses conventional Transform nodes. I am not sure what the reason for this is. Perhaps the objects that share the same internal Transform node are not shared but created for each primitive by the 3d engine.

If this is the case we should see a performance increase if we make all the spheres into one single IndexedFaceSet
oneIFSSpeedTest.wrl is such an example. I get:

11.03fps  28 primitives 54857 triangles

this is a significant improvement! it also goes to show that if you use optimization techniques like in our triangleSphereMatrixSpeedTest.wrl and not test our theory we may be experiencing pain with no gain.
Comparing sphereSpeedTest.wrl to oneIFSSpeedTest.wrl demonstrates how IndexedFaceSets can well and truly out perform higher level nodes like Sphere nodes. Because spheres are on a to higher level, we can't get to their vertices to tweak them like we can with the lower level IndexedFaceSet node.