开发者社区> 问答> 正文

算法耗时随运算量变化的影响 400 请求报错 

进行一个复杂运算, 方案①,耗时:200毫秒,实现麻烦,代码冗长 方案②,耗时:400毫秒,实现简单,代码优雅


观点一:认为方案②比方案①仅慢200毫秒,这点时间可以忽略不记。 观点二:任务方案②的耗时是方案①的2倍,当单位耗时延长,方案②的耗时也将倍增。


纠结哪种观点靠谱呢?

展开
收起
kun坤 2020-05-30 22:45:48 631 0
1 条回答
写回答
取消 提交回答
  • 看数据量咯,也就是那200ms的价值,在可观的未来,如果数据量会暴涨,上方案2######在大家心里可以承受的时间范围内就方案2。 假如批量数据处理方案2需要1个小时,这时候方案1的重要性来了,毕竟时间减少了一半。######数据量增多到预想的情况下,你跑一下看看能否接受这种效率,能的话方案2。。当然从性能来讲当然选方案1了######确认算法保证没错的情况用1######刨除数据量、硬件成本、时间成本,没法判断的。 真实处理的数据量是多少,能否通过分布式提高效率,可以接受的最长业务处理时间是多少?离开这些谈算法,都是没意义的。 实际上,现代的计算时间早就是大白菜了,所以99.99%的时候,算法2都比1要合适。虽然慢一倍,但是算法的排错修改时间肯定远远小于1,至于慢的速度,拿十倍20倍的硬件堆就是。######

    引用来自“魔力猫”的评论

    刨除数据量、硬件成本、时间成本,没法判断的。 真实处理的数据量是多少,能否通过分布式提高效率,可以接受的最长业务处理时间是多少?离开这些谈算法,都是没意义的。 实际上,现代的计算时间早就是大白菜了,所以99.99%的时候,算法2都比1要合适。虽然慢一倍,但是算法的排错修改时间肯定远远小于1,至于慢的速度,拿十倍20倍的硬件堆就是。

    用硬件对不妨是一个解决办法,但还是要结合实际的业务场景来决定的 关键还是要看你这个计算再在你整个要解决的业务场景中所占的比重,比重越高性能要求越高######再写一层封装,自动选择算法不就行了吗。 比如说什么情况下用算法1,什么情况下用算法2。这样还有个扩展性的好处,以后你又发现了新算法。你还可以加在里面,什么时候用算法3都是没有问题的。######一个运算就消耗200ms,A星寻路算法(图形寻路比较高效且适用性比较广以及相对复杂的逻辑算法,在此随便举例而已),如果是这个时间级别都得使劲优化。400ms的方案二直接pass掉,哪怕方案一只耗时200ms,你测试一下并发量看看,耗时100ms的业务并发就很糟糕了(单机情况),自己实测一下你就知道200ms的差距是什么概念了。 如果并发情况加锁同步执行一个200ms耗时的算法,加锁同步也就可以理解为顺序执行,你想想1s也就执行5次而已,那些说堆硬件的简直胡扯,堆硬件只是没办法的办法。哪怕是方案一,我觉得如果还有优化的空间还得优化。 如果软件没有并发需求,即不会有多用户同时触发执行此算法的情况下,方案二当然是可以的。######有条件的情况,当然是越快的算法越好,根据数据量取优的话,需要大量测试,根据曲线取临界值的

    2020-05-30 22:45:53
    赞同 展开评论 打赏
问答分类:
问答地址:
问答排行榜
最热
最新

相关电子书

更多
数据+算法定义新世界 立即下载
袋鼠云基于实时计算的反黄牛算法 立即下载
Alink:基于Apache Flink的算法平台 立即下载