当前位置: 首页 > 面试题库 >

什么时候应该使用Map而不是For Loop?

和和煦
2023-03-14
问题内容

这与以下内容有关:(在Python代码中)

for i in object:
     doSomething(i)

map(doSomething, object)

两者都很容易理解,而且简短,但是速度之间有区别吗?现在,如果doSomething有一个返回值,我们需要检查它是否会从map中以列表的形式返回,并且在for循环中,我们可以创建自己的列表或一次检查一个列表。

for i in object:
     returnValue = doSomething(i)
     doSomethingWithReturnValue(returnValue)

returnValue = map(doSomething, object)
map(doSomethingWithReturnValue, returnValue)

现在,我觉得两者有些分歧。这两个doSomethingWithReturnValue函数可能会有所不同,这取决于我们在循环过程中即时检查它们还是最终一次检查所有它们产生不同的结果。同样,for循环似乎总是可以工作,甚至可能更慢,在这种情况下,映射仅在某些情况下才可以工作。当然,我们可以做出曲解以使任何一种工作都可行,但是重点是要避免这种工作。

我要寻找的是这样一种场景,与性能,可读性,可维护性或实现速度方面的出色循环相比,映射功能确实发光。如果答案确实没有太大的区别,那么我想知道在实践中人们何时使用一个或另一个,或者它是否真的完全是任意的,并根据您所在的机构通过编码标准进行设置。

谢谢!


问题答案:

map当您要将函数应用于可迭代项的每个项目并返回结果列表时,此函数很有用。这比使用for循环和构造列表更为简单和简洁。

for在其他情况下通常更具可读性,并且至少有很多迭代构造基本上是使用宏和map编写的。因此,在map不合适的情况下,请使用for循环。

从理论上讲,如果我们有一个足够聪明的编译器/解释器以使用多个cpus
/处理器,那么map由于可以并行完成每个项目上的不同操作,因此可以更快地实现。不过,我认为目前情况并非如此。



 类似资料:
  • 问题内容: 我是一名C ++程序员,偶尔使用MySQL处理数据库,但是我的SQL知识非常有限。但是,我当然愿意改变这一点。 目前,我正尝试仅通过SQL查询对数据库中的数据进行分析(!)。但是我将放弃,而是将数据导入C 并使用C 代码进行分析。 我已经与同事讨论了这一点,他们也促使我使用C ++,他说SQL并不是用于复杂的分析,而是主要用于导入(从现有表中)和导出(到新表中)数据,还有更多内容。例如

  • 问题内容: 我知道他们两个都禁用了Nagle的算法。 我什么时候应该/不应该使用它们中的每一个? 问题答案: 首先,不是所有人都禁用Nagle的算法。 Nagle的算法用于减少有线中更多的小型网络数据包。该算法是:如果数据小于限制(通常是MSS),请等待直到收到先前发送的数据包的ACK,同时累积用户的数据。然后发送累积的数据。 这将对telnet等应用程序有所帮​​助。但是,在发送流数据时,等待A

  • 问题内容: 在该类中,有两个字符串,和。 有什么不同?我什么时候应该使用另一个? 问题答案: 如果你的意思是和则: 用于在文件路径列表中分隔各个文件路径。考虑在上的环境变量。您使用a分隔文件路径,因此在上将是;。 是或用于拆分到特定文件的路径。例如在上,或

  • 问题内容: 编码要发送到Web服务器的查询字符串时-您何时使用以及何时使用或: 使用转义: 要么 使用encodeURI()/ encodeURIComponent() 问题答案: escape() 不要使用它! 在B.2.1.2节中定义了转义,并且附件B的引言中指出: …本附件中指定的所有语言功能和行为均具有一个或多个不良特征,在没有遗留用法的情况下,将从本规范中删除。… …程序员不应该使用或编

  • 问题内容: 流式XML解析器(例如SAX和StAX)比构建像DOM解析器之类的树结构的解析器更快,内存效率更高。SAX是推送分析器,这意味着它是观察者模式(也称为侦听器模式)的实例。SAX首先出现,然后是StAX- 拉式解析器,这意味着它基本上像迭代器一样工作。 您可以找到在任何地方都偏爱StAX而不是SAX的原因,但是通常可以归结为:“更易于使用”。 在JAXP上的Java教程中,StAX被模糊

  • 问题内容: 在本文中, Nick Coghlan讨论了PEP 435类型的 一些设计决策,以及如何将其子类化以提供不同的体验。 但是,我给出的建议(我是stdlib的主要作者)关于使用元类的建议是,在没有充分好的理由的情况下不应该这样做- 例如,无法使用类装饰器或专用工具来完成所需的工作隐藏任何丑陋的功能;而在我自己的工作,我已经能够做到我需要什么简单的使用,在创建时,和/或正常类/实例方法类:

  • 问题内容: 实际上,这是一个类似的话题,几乎没有实用价值。据我了解,原语性能更好,除需要与对象相关的功能(例如检查)外,应在所有地方使用。对? 问题答案: 别忘了,由于为每次装箱而创建一个新的包装程序都是非常昂贵的,尤其是考虑到通常在一种方法的单个作用域中使用它,因此自动装箱将使用一组通用包装程序。 这实际上是flyweight设计模式的一种实现。当对一个众所周知的值进行装箱时,而不是创建一个新的

  • 最近,我收到了在代码中使用's的建议,或者在站点上看到了一些使用's的答案--应该是某种容器。但是--我在C++17标准库里找不到类似的东西。 那么这个神秘的是什么?如果它是非标准的,为什么(或何时)使用它是个好主意?