Counter Strike GO runs at 64 or 128 updates per second; it is left up to the user to choose their desired refresh rate for their computer or for their dedicated server.
For an FPS game like CSGO or some other action packed or sporty video game the excess updates beyond 60 improves online response and precision; so higher FPS will improve gameplay, it will not improve the look of the game.
Professional video game players; yes they exist; will swear by setting high refresh rates.
You cannot perceive 120 visual frames per seconds as TheComet pointed out; you only notice frame stuttering low frame rates depending on how good your eyes are.
You can think of the DBPRO sync command as a batch rendering call; as well as a windows message update. All the objects are Z sorted, shortlisted, shaded and rendered for each active camera.
You could bypass a sync call every so often if your frame-rate is optimal. Your game can be sync-paused or re-looped without a sync call because it might not be necessary to render what is on screen if what is visible has not changed.
In my game the physics has dynamic iteration, so the host of the game can run a number of physics loops before the next render if any frames have been dropped, or the physics iterations can be reduced or paused if the system is running extremely fast. Catmull-rom interpolation will be used to guess where things are during stuttering and major slow-downs.
Two of DBPRO's performance weaknesses is the object pipeline and bone animation. These processes reside in the sync call and are a potential threat to your FPS particularly when such objects are in the screen.
To create a room with windows and doors, you can save performance by making each aspect of the room a limb. Even better, would be to make all static objects in the room the same limb with an atlas based texture. These kinds of facts come through regular testing and tweaking.
Another threat to FPS is excessive 2D drawing calls; without using a plugin like D3DFunc or my preference Advanced2D.
