【问题标题】:What's the time complexity for downcasting an object?向下转换对象的时间复杂度是多少?
【发布时间】:2019-07-25 21:15:12
【问题描述】:

我从 RPC 服务收到了一个通用的 Object 类型实例,我想将它转换为 MyClass 类型实例,这个操作的时间复杂度是多少?性能对我的应用程序至关重要。 (适用于 Java 和 C# 等语言)

例如:Employee employee = (Employee) person;PurchaseData purchaseData = (PurchaseData) genericData;

【问题讨论】:

  • 转换是在编译时解决的,所以在运行时并不重要
  • 如果是编译时动作,那为什么会出现运行时转换失败?
  • 因为你在编译时说:“我 assume x 是一个 X”。在运行时,x 仍然可能是 Y。强制转换是对编译器的指令,告诉编译器:“我比你更清楚,这里的 x,我认为它是 X,所以请对待就这样”。
  • OP 将 Java 和 C# 混为一谈,确实是在自取其辱。它们是具有不同运行时和编译时行为的不同语言。结果,他们得到了混乱的相互交织的反应。我的建议是就单一语言提出这类问题。仅仅因为 2 种语言具有“相似”的语法,并不意味着它们的行为应该相同。
  • 澄清请求:您的问题得到充分回答了吗?如果是这样,请考虑accepting 一个答案。这样做有助于未来的读者确定问题是否已解决,并对花时间回答您的人表示感谢。否则请提供反馈,以便人们进一步调整他们的答案。

标签: java c# optimization casting time-complexity


【解决方案1】:

铸造首先是一个编译时间的活动。

在运行时,如果有的话,假设 O(1)。你看,当代码被执行时,所有这些信息(如类结构)都是固定的

鉴于注释:假设您的 Object 被反序列化为 X 类的实例,那么 JVM 已经知道该对象实际上是 X 类。该对象存在于内存中,并且它的确切类只需查找一次!

除此之外:假设您的对象是通过某种 RPC 调用进入的,并且它们从某种传输表示形式反序列化到 JVM 对象中...您真的认为时间对于铸造事项?调用远程服务可能需要几毫秒,甚至几秒钟。而且您担心以后投射此类对象是否需要 5 纳秒或 15 或 25 纳秒?

唯一可能导致显着性能的情况:当该转换出错时,您会遇到 ClassCastException。

【讨论】:

  • 如果我从 RPC 服务收到通用 Object 类型实例怎么办?
  • 这与每个演员需要多长时间无关,因为它不可避免地需要完成。这是关于我们进行这种转换和设计的次数:一次转换并传递实例或将通用实例向下传递并在需要它们的多个位置进行转换(多次转换)。
  • 无论如何,向下转换都是糟糕设计的征兆。别搞错了:在 2018 年,您应该尝试设计一个系统,让您在正确的时间收到您的物品。 JVM 在反序列化时知道确切的类型,因此请确保定义返回这些类型的接口,而不是 Object。
  • 我完全同意你的观点,但我实际上是数据的消费者,我只是设计系统来消费数据。
  • 我只能重复一遍:如果 casting 对象成为您系统的性能瓶颈,那么您就没有性能问题。再次重申:仅(反)序列化 single 对象的行为很容易导致数十万条 CPU 指令。反序列化后,它的类型是已知的。并且继承树也是已知的。所有这些都是静态信息,不会改变。您正在认真地将时间和精力花在系统的错误方面。一个不需要半秒就阻塞的方法调用将弥补大量的强制转换。
猜你喜欢
  • 2016-04-11
  • 1970-01-01
  • 2020-07-30
  • 2014-01-14
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多