并发方法是加速长时间迭代的好主意吗？

发布于 2024-09-16 04:36:12 字数 1036 浏览 12 评论 0原文

我有一个应用程序，它会随着时间的推移进行迭代以在图表上创建点。当我收集 x 轴上每个点的数据时，我还必须执行递归查找，这实际上意味着我在另一个循环中有一个循环。这扩展得不太好。我没有看到很多在迭代中使用“分而治之”解决方案的例子。我正在考虑使用 Java 的执行器并发框架在它自己的线程中运行每个循环，等待答案，收集结果并返回它们。我得到的初步测试结果似乎并没有那么快。我知道我应该展示一些代码，但我首先想知道的是，与我可能不熟悉的更好方法相比，这种方法是否具有优点。提前致谢！

添加一些 groovyish/javaish 伪代码来帮助思考这个问题：

class Car {
    id
    model 
    make
    weight
}

for (number in listOfImportantCarIDs) {
    Car car = carsMap.get(number) // find the car we care about
    String maker = car.make //get it's 'parent' 

    // get amount of all related cars
    Iterator<Car> allcars = carsMap.values().iterator();
    while (allcars.hasNext()) {
        Car aCar = alldocs.next();
        if (maker.equals(aCar.make)) {
            totalCarCount++;  // increment total related cars 
            BigDecimal totalWeightofAllCars = totalWeightofAllCars.add(aCar.getWeight()); // add weight to total

            // a ghetto cache to prevent double  counting
            countedMaufacturers.add(make); 
        }     
    }
}

原文

I have an app that does an iteration to create points on a graph over time.
While I'm gathering data for each point across the x-axis I also must execute a recursive lookup which effectually means I have a loop inside another loop. This is not scaling too well. I don't see a lot of examples of using a "divide and conquer" solution on iterations. I was thinking of using Java's Executor concurrency framework to run each loop in it's own thread, await the answers, gather the results and return them. The initial test results I'm getting don't seem that much faster. I know I should show some code but what I want to know first is if this approach has merit compared to better methods that I may not be familiar with.
Thanks in advance!

Adding some groovyish/javaish pseudo code to assist thinking about this:

class Car {
    id
    model 
    make
    weight
}

for (number in listOfImportantCarIDs) {
    Car car = carsMap.get(number) // find the car we care about
    String maker = car.make //get it's 'parent' 

    // get amount of all related cars
    Iterator<Car> allcars = carsMap.values().iterator();
    while (allcars.hasNext()) {
        Car aCar = alldocs.next();
        if (maker.equals(aCar.make)) {
            totalCarCount++;  // increment total related cars 
            BigDecimal totalWeightofAllCars = totalWeightofAllCars.add(aCar.getWeight()); // add weight to total

            // a ghetto cache to prevent double  counting
            countedMaufacturers.add(make); 
        }     
    }
}

分享到QQ

分享到微博

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

发布评论

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

一世旳自豪 2024-09-23 04:36:12

使用线程可以使应用程序加速一些小的常数因子，但代价是显着增加线程间通信的复杂性。如果存在更好的算法，那么可以节省几个数量级。因此，我强烈建议您首先验证是否确实没有次二次算法可以解决您的问题。

也许如果您详细说明了您要解决的问题以及当前的解决方案，我们可以在这里提供帮助。

编辑：天哪，找到一个更好的算法一点也不难：

for (Car car : cars {
    Stats s = stats.get(car.maker);
    if (s == null) {
        s = new Stats();
        stats.put(car.maker, s);
    }
    stats.count++;
    stats.totalWeight+=car.weight;
}

for (Car car in importantCars) {
    stats.get(car.maker);
}

对于每辆重要的汽车，实际上没有必要迭代所有汽车，只是为了找到具有相同制造商的汽车......

Using threads will speed up your application by some small constant factor, at the price of significant added complexity for inter-thread communication. If a better algorithm exists, that can save you orders of magnitude. Therefore, I strongly recommend that you first verify that there indeed isn't a sub-quadratic algorithm to solve your problem.

Perhaps if you detailed the problem you are trying to solve and your current solution, we could assist here.

Edit: Goodness, finding a much better algorithm isn't hard at all:

for (Car car : cars {
    Stats s = stats.get(car.maker);
    if (s == null) {
        s = new Stats();
        stats.put(car.maker, s);
    }
    stats.count++;
    stats.totalWeight+=car.weight;
}

for (Car car in importantCars) {
    stats.get(car.maker);
}

There really is no need to iterate, for each important car, over all cars just to find those with identical maker ...

回复收藏 0 原文