官术网_书友最值得收藏!

Sharing calculation output

Performance can be saved by having multiple objects share the result of some calculation; of course, this only works if all of them generate the same result. Such situations are often easy to spot but can be tricky to refactor, and so exploiting this would be very implementation-dependent. 

Some examples might include finding an object in a scene, reading data from a file, parsing data (such as XML or JSON), finding something in a big list or deep dictionary of information, calculating pathing for a group of Artificial Intelligence (AI) objects, complex mathematics-like trajectories, raycasting, and so on.

Think about each time an expensive operation is undertaken, and consider whether it is being called from multiple locations but always results in the same output. If this is the case, then it would be wise to restructure things so that the result is calculated once and then distributed to every object that needs it to minimize the amount of recalculation. The biggest cost is typically just a small loss in code simplicity, although we may inflict some extra overhead by moving the value around.

Note that it's often easy to get into the habit of hiding some big complex function in a base class, and then we define derived classes that make use of that function, completely forgetting how costly that function is because we rarely glance at that code again. It's best to use the Unity Profiler to tell us how many times that expensive function may be called, and as always, don't preoptimize those functions unless it's been proven to be a performance issue. No matter how expensive it may be, if it doesn't cause us to exceed performance restrictions (such as frame rate and memory consumption), then it's not really a performance problem.

主站蜘蛛池模板: 宿州市| 阳谷县| 竹北市| 万安县| 通州市| 乐清市| 银川市| 张家界市| 抚远县| 隆回县| 安丘市| 黄陵县| 平舆县| 大连市| 新宁县| 遂川县| 剑河县| 张家口市| 五莲县| 定南县| 朝阳市| 洪泽县| 常山县| 台前县| 禄丰县| 塔城市| 长治市| 鄂伦春自治旗| 页游| 芮城县| 葫芦岛市| 兴和县| 根河市| 汽车| 屏东县| 娄烦县| 个旧市| 佛山市| 岱山县| 清镇市| 虎林市|