仅仅是一个地图的find查询，就被主程说成是影响服务器效率
仅仅是一个map的find查询，就被主程说成是影响服务器效率。
功能需求很简单，玩家在世界频道聊天会扣玩家的钱，和检测玩家等级够不够，
服务器启动的时候，会从脚本读取扣多少钱以及级别限定，然后我把这2个值保存到了std::map里，
然后服务器每收到玩家一次聊天，我就用这个map查询扣钱和级别限制，像这样：
GetProperty("MoneyCost");
GetProperty("LevelLimit");
这个函数，只有一条语句，那就是执行std::map的find语句，
然后我主程就跑过来，说你不能每次都find，你要把这两个值在服务器初始化的时候保存成成员变量，用成员变量，而不是每次
都find
各位觉得，这种要求是不是太无理了？
------解决方案--------------------
谁是你顶头上司听谁的。
------解决方案--------------------
+1
------解决方案--------------------
效率的话主要看map数据有多少了，有没有必要要看执行函数的频度
------解决方案--------------------
效率跟map里数据量有关吧。如果就两个值，也没必要弄个map，再专门写个函数去读数据。弄成成员变量确实是最好的
------解决方案--------------------
听领导的吧，效率方面应该是用成员变量会合理一些
------解决方案--------------------
过早的优化是万恶之源。
------解决方案--------------------
数据说话呀,用hash_map
理论上hash_map比map效率要高很多，一个查找时是接近O(1)，一个是O(lg N)，数量级就不一样；
------解决方案--------------------
------解决方案--------------------
减少不必要的运算（编译时运算，cache）是优化中常见的手段。
------解决方案--------------------
如果这程序就这么2个属性，也不会经常增加新属性，写死为成员变量肯定比map用string做key去查要快一些。
------解决方案--------------------
我到觉得如果真的有100个配置信息，存成员变量比存到map里更好。对以后维护代码更直观些。而且配置信息能有多少项
------解决方案--------------------
因为map里面的数据已经是在内存了，所以你保存在成员变量里还是保存在map里，对于现在的处理器来说，效率上应该不是影响很大吧。保存在成员变量上，相当于用了两份内存保存同一份数据，也得实现同步等，并不一定可取。
在以后用户量多了，map容量大了，查询的频率也上去了，影响了效率，再去优化应该也来的及吧。
------解决方案--------------------
之前看一个小日本的程序源码，配置信息30多项用struct保存，类里定义一个struct成员变量，感觉挺好。
------解决方案--------------------
个人意见：不超过1000的循环不考虑效率。
参考下面：
＜1000个元素，冒泡排序
＜100000个元素，qsort函数
＜10000000个元素，放数据库中，建索引，（B+树排序）
≥10000000个元素，没用到过。
------解决方案--------------------
如果已经有一个玩家的类实例了当然这些信息作为他的成员变量是自然合理的。何必弄一个map的。服务端程序对性能的过分苛求是合理的。
我看问题在于主程在沟通的态度上让你不好接受。如果要否定一个苛求的设计，正确的方式应该是先用充分的理由让你明白其中的利害关系。
------解决方案--------------------
如果调用频率很高的话，在服务器端，微小的性能差异带来的差别是巨大的，如果说一个函数可能在一秒钟之内调用1万次，普通函数和inline的差别就是巨大的了。压栈出栈在这种情况下就是一笔很大的耗费。
------解决方案--------------------
我觉得还好。
主程的优点是减少函数调用，故效率可能要好一点（估计也提高不了多少）。但不太灵活。
------解决方案--------------------
如果这个函数调用非常频繁，确实需要考虑。
------解决方案--------------------
我还是比较顶LZ的，有时过于纠结效率并不好，特别是像这种配置信息，很容易变动的，用map之类的容器可能更好，因为一旦变动，改类的成员代价会打得多。我觉得对于效率的优化应该放在关键代码上，细致末节的地方开发效率更重要。而且很多东西就算一种方法比另一种方法快100倍，但若是两种方法的花销对整个工程都是忽略不计的，我个人认为对其选择完全可以不考虑效率。
不过话说回来，人在屋檐下，不得不低头，上司怎么说，下属只能怎么做~
------解决方案--------------------
你经验不足，你主程说的是对的。你应该感谢他给你指出了问题。
定义成变量也不一定就缺乏灵活性，很多都是用配置工具生成的源码，框架写的好不会有灵活性问题。
功能需求很简单，玩家在世界频道聊天会扣玩家的钱，和检测玩家等级够不够，
服务器启动的时候，会从脚本读取扣多少钱以及级别限定，然后我把这2个值保存到了std::map里，
然后服务器每收到玩家一次聊天，我就用这个map查询扣钱和级别限制，像这样：
GetProperty("MoneyCost");
GetProperty("LevelLimit");
这个函数，只有一条语句，那就是执行std::map的find语句，
然后我主程就跑过来，说你不能每次都find，你要把这两个值在服务器初始化的时候保存成成员变量，用成员变量，而不是每次
各位觉得，这种要求是不是太无理了？
------解决方案--------------------
谁是你顶头上司听谁的。
------解决方案--------------------
+1
------解决方案--------------------
效率的话主要看map数据有多少了，有没有必要要看执行函数的频度
------解决方案--------------------
效率跟map里数据量有关吧。如果就两个值，也没必要弄个map，再专门写个函数去读数据。弄成成员变量确实是最好的
------解决方案--------------------
听领导的吧，效率方面应该是用成员变量会合理一些
------解决方案--------------------
过早的优化是万恶之源。
------解决方案--------------------
数据说话呀,用hash_map
理论上hash_map比map效率要高很多，一个查找时是接近O(1)，一个是O(lg N)，数量级就不一样；
------解决方案--------------------
------解决方案--------------------
减少不必要的运算（编译时运算，cache）是优化中常见的手段。
------解决方案--------------------
本帖最后由 qq120848369 于 2014-01-08 16:12:35 编辑
从效率角度考虑的话，主程说的没什么问题。如果这程序就这么2个属性，也不会经常增加新属性，写死为成员变量肯定比map用string做key去查要快一些。
------解决方案--------------------
我到觉得如果真的有100个配置信息，存成员变量比存到map里更好。对以后维护代码更直观些。而且配置信息能有多少项
------解决方案--------------------
因为map里面的数据已经是在内存了，所以你保存在成员变量里还是保存在map里，对于现在的处理器来说，效率上应该不是影响很大吧。保存在成员变量上，相当于用了两份内存保存同一份数据，也得实现同步等，并不一定可取。
在以后用户量多了，map容量大了，查询的频率也上去了，影响了效率，再去优化应该也来的及吧。
------解决方案--------------------
之前看一个小日本的程序源码，配置信息30多项用struct保存，类里定义一个struct成员变量，感觉挺好。
------解决方案--------------------
个人意见：不超过1000的循环不考虑效率。
参考下面：
＜1000个元素，冒泡排序
＜100000个元素，qsort函数
＜10000000个元素，放数据库中，建索引，（B+树排序）
≥10000000个元素，没用到过。
------解决方案--------------------
如果已经有一个玩家的类实例了当然这些信息作为他的成员变量是自然合理的。何必弄一个map的。服务端程序对性能的过分苛求是合理的。
我看问题在于主程在沟通的态度上让你不好接受。如果要否定一个苛求的设计，正确的方式应该是先用充分的理由让你明白其中的利害关系。
------解决方案--------------------
如果调用频率很高的话，在服务器端，微小的性能差异带来的差别是巨大的，如果说一个函数可能在一秒钟之内调用1万次，普通函数和inline的差别就是巨大的了。压栈出栈在这种情况下就是一笔很大的耗费。
------解决方案--------------------
我觉得还好。
主程的优点是减少函数调用，故效率可能要好一点（估计也提高不了多少）。但不太灵活。
------解决方案--------------------
如果这个函数调用非常频繁，确实需要考虑。
------解决方案--------------------
我还是比较顶LZ的，有时过于纠结效率并不好，特别是像这种配置信息，很容易变动的，用map之类的容器可能更好，因为一旦变动，改类的成员代价会打得多。我觉得对于效率的优化应该放在关键代码上，细致末节的地方开发效率更重要。而且很多东西就算一种方法比另一种方法快100倍，但若是两种方法的花销对整个工程都是忽略不计的，我个人认为对其选择完全可以不考虑效率。
不过话说回来，人在屋檐下，不得不低头，上司怎么说，下属只能怎么做~
------解决方案--------------------
你经验不足，你主程说的是对的。你应该感谢他给你指出了问题。
定义成变量也不一定就缺乏灵活性，很多都是用配置工具生成的源码，框架写的好不会有灵活性问题。