You may receive hundreds of sensor data updates per second, but usually there is no need to update the screen more frequently than about 60Hz (and if your scene is complex then you may want limit refresh rate to a lower value to have some spare time on the main thread to do other things than rendering). Of course you also need to minimize changes in the update loop: you should pre-create all objects in advance and just update their properties (to avoid doing unnecessary computations and memory fragmentation).
In 3D Slicer we solved visualization of position-tracked instruments and live interventional imaging data by using “request render” mechanism implemented in CTK toolkit and do all sensor data collection and preprocessing in background threads. If you implement a medical application that I would strongly recommend to use these components that proven to work robustly in the operating room for various procedures (see www.slicerigt.org). If you work in a different domain then you can take source code or ideas from 3D Slicer and its extensions.
Things getting slower in each iteration means that you don’t pre-create all objects in advance but you create new instances in each iteration (and maybe not even clean them up properly).