对象池和 CSLA 框架

发布于 2024-10-05 23:13:06 字数 1128 浏览 6 评论 0原文

我有一个遵循 CSLA 框架中基本方法的应用程序。具体来说,对象知道如何维护其状态以及如何创建、更新、删除自身。汽车类就体现了这个想法。

public class Car
{
    public int Color {get;set;}
    public void Drive(){.. Do something Here}
    private Car(){} // Only factory method can create this object
    public static Car New()
    {
        Car car = new Car();
        car.DataFetch();
        return car;
    }
    private void DataFetch()
    { 
        // Fill up this object with values from DB or where ever
        this.Color = repo.valueForColor();
        // ...
    }
}   

该应用程序创建和销毁了超过 100 万个对象,并且由于正在进行的垃圾收集量,对象创建的剪切数量正在影响性能。此外,其中许多对象是完全暂时的,用于简单地将数据传递到存储库中。

我读过有关 flyweight 模式 的内容,看起来它可能适合我的需求。我还阅读了对象池和相关的代码

我遇到的麻烦是使用池创建一百万个 Car 对象,或者结合对象应该维护其自己的数据和数据访问的原则将数据外部化为享元。

关于如何实现这一目标有什么想法吗?

I have an application that follows the basic methodoligy in the CSLA framework. Specificly, the objects know how to maintain their state and how to create, update, delete themselves. The car class shows this idea.

public class Car
{
    public int Color {get;set;}
    public void Drive(){.. Do something Here}
    private Car(){} // Only factory method can create this object
    public static Car New()
    {
        Car car = new Car();
        car.DataFetch();
        return car;
    }
    private void DataFetch()
    { 
        // Fill up this object with values from DB or where ever
        this.Color = repo.valueForColor();
        // ...
    }
}   

The application creates and destroys over 1 Million objects and the shear number of object creation is impacting performance due to the amount of garbage collection going on. Also a lot of these objects are completely transitory and are used to simply pass data onto the repository.

I've read about the flyweight pattern which seems like it may suit my needs. And I've also read about Object Pooling and the associated code.

What I'm having trouble with is creating a million Car objects using a pool or externalizing the data for a flyweight in conjunction with the principle of the Object should maintain it's own data and data access.

Any ideas on how to accomplish this?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

差↓一点笑了 2024-10-12 23:13:06

确保您的对象生成确实具有影响力。对象生成和 GC 在 sql server 中很便宜,并且涉及到数据库。 IO 确信 ap rofilder 会告诉您,影响性能的不是对象创建和销毁,而是首先拉取 100 万个对象。

事实上,拉取对象应该比创建对象并销毁它慢 1000 倍。

特别是一些可笑的低效代码,例如

this.Color = dataReader.get("颜色");

这是每辆车的哈希表查找。存储字段的索引(或者知道它,它在 sql 运行之间不会改变)并使用索引怎么样?仅此一点就会比任何其他方法给您带来更多。特别是如果您还发出一百万条单独的 SQL 语句 - 正如您似乎所做的那样。

像往常一样进行性能优化时:运行分析器。就你而言,你100%的想法是错误的,你在浪费时间。你会发现对象创建和GC甚至没有出现在前10个性能浪费者中。

Make sure your object generation really impacts. Object generation and GC is CHEAP in sql server, and you have a database involved. IO am sure ap rofilder will show you it is NOT the object craetion and destruction that is impacting your performance, but pulling 1 million objectsin the first place.

In fact, pulling the bject should be 1000 times slower than creating the obejct AND destroying it.

Especialyl wih ridiculous inefficient code like

this.Color = dataReader.get("Color");

which is a hashtable lokoup for every car. What about storing the index of the field (or knowing it, it does not change between sql runs) and using the index? That alone will bring you more than any other approach. Especially if yuo also issue one million separate SQL Statements - as you seem to do.

Like always when doing performance optimizations: RUN A PROFILER. In your case you are 100% on the wrong idea where you are wasting your time. You will find out that object creation and gc do not even show up in the top 10 performance wasters.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文