【问题标题】:Performance concerns of instantiating a class multiple times多次实例化一个类的性能问题
【发布时间】:2009-05-15 18:58:08
【问题描述】:

我想知道在表单中实例化一个类或在需要时实例化一个类之间的性能差异。例如,假设我有一个客户表单来编辑客户。在表单加载时,我实例化一个客户类并调用一个函数来返回客户数据以填充表单控件。

CustomerInfo customer = new CustomerInfo();
CustomerDetail  cust = customer.GetCustomer(customerId);
txtName. cust.Name;
...

表单上还有一个保存按钮。单击该按钮时,我会创建另一个 Customer 类实例来更新数据。

CustomerDetail cust = new CustomerData();
cust.Id = customerId;
cust.Name = txtName.Text;

CustomerInfo customer = new CustomerInfo();
customer.Update(cust);

我知道这很好用。但是,在性能方面是否更好,只是为整个表单创建一个 Customer 类的实例来调用 GetCustomer 和 Update?我知道 GC 会处理这些实例,但我不确定它会在继续下一个实例之前破坏第一个实例。

另外,这个例子我只使用了两个对客户类的函数调用,但实际上,可能还有更多。

感谢您的帮助。

【问题讨论】:

    标签: c# .net performance


    【解决方案1】:

    您的想法应该是为您正在操作的每个不同客户创建一个 Customer 实例。因此,如果您的表单只处理一个客户,那么您应该只有一个实例,但如果您的表单处理多个客户,那么您将有多个实例。

    就性能而言,只有在处理许多实例时才会成为问题,我会说数千个。

    【讨论】:

    • 我真的很喜欢这个比喻,很有道理。谢谢!
    【解决方案2】:

    过早的优化是万恶之源。

    在您为最佳可读性编写了一个解决方案并发现它不足以通过测试客户规范的测试之前,永远不要考虑优化。

    如果您的优化未通过未优化版本失败的相同测试,请恢复它。

    【讨论】:

      【解决方案3】:

      就我个人而言,我会将实例与表单一起保留。一遍又一遍地实例化它似乎是不必要的开销。我同意 Vincent Ramdhanie 的观点,即每个客户拥有一个实例,因此如果您更换客户,您应该获得一个新实例。

      此外,通过将实例保留在您身边,您可以轻松检查它是否真的发生了变化,如果在持续更改方面存在相当大的开销,我倾向于这样做。但这是另一个问题。

      【讨论】:

        【解决方案4】:

        我会将该功能移至 CustomerRepository 类,并在我的应用程序中拥有该功能的单个实例,在创建/加载表单时创建

        即。获取/保存客户数据代码。

        【讨论】:

          【解决方案5】:

          当您需要使用相同的表单更新或创建“客户”时,单个实例的方法很有用。

          【讨论】:

            【解决方案6】:

            当然,不重新创建对象的开销更少。此外,当您持有对象时,可能存在某种程度的数据隐式锁定(否则,如果其他人可以访问数据库,或者除非您不关心更新冲突,您需要对数据进行某种外部锁定)。

            此外,按照上述方式进行操作假设您的表单知道 所有属于 CustomerData 的字段 - 您没有保留原始对象并对其进行更新,因此您最好让确保您从中获取了所有数据并手动将其传输到“新”对象。然后你的代码变得与 CustomerData 的定义(和实现)紧密相关——如果有人添加了可见字段,你的代码需要修改。如果他们添加了“隐藏”字段或状态,那么您的代码真的需要修改。

            所以我建议保留对象并更新它,并单独(根据需要)处理任何锁定要求。

            【讨论】:

              猜你喜欢
              • 1970-01-01
              • 1970-01-01
              • 1970-01-01
              • 1970-01-01
              • 1970-01-01
              • 1970-01-01
              • 1970-01-01
              • 1970-01-01
              • 2018-06-30
              相关资源
              最近更新 更多