Максимальный разброс производительности ACF против Lucee

Следующий код для поиска простых чисел значительно отличается от Adobe ColdFusion (10) и Lucee (4.5) относительно производительности. Протестировано на том же компьютере (6C i7 3930k @4 ГГц, Windows 10 64 бит, настройки памяти JVM равны на обоих CFML-машинах: JDK7 -Xms512m -Xmx2048m -XX:MaxPermSize=512m):

<cfscript>
    ticks = getTickCount();
    stopIndex   = 10000;
    primes      = [];
    divisions   = 0;
    primes.add(2);
    primes.add(3);
    n = 5;
    for (n; n < stopIndex; n += 2) {
        isPrime = true;
        d = 3;
        for (d; d < n; d++) {
            divisions++;
            if (n % d == 0) {
                isPrime = false;
                break;
            }
        }
        if (isPrime) {
            primes.add(n);
        }
    }
    ticks = (getTickCount() - ticks);
</cfscript>

<cfoutput>
    <p>
        #numberFormat(divisions)# divisions in #ticks# ms.
    </p>
    <p>
        #numberFormat(arrayLen(primes))# prime numbers found below #numberFormat(stopIndex)#.
    </p>
</cfoutput>

stopIndex @10k

ACF: 280 мс
LUC: 1300 мс

stopIndex @20k

ACF: 1000 мс
LUC: 4800 мс

stopIndex @30k

ACF: 2200 мс
LUC: 10500 мс

trycf.com и cflive.net показывают аналогичный пробел.

Я проверил, влияет ли cfscript (против тегов) на время, это не так. Параметры сервера, связанные с двигателем CFML, похоже, не имеют никакого заметного воздействия.

Что может быть причиной разницы в производительности?
И как я могу это решить?

Фон: я запускаю тяжелые математические операции (геометрия, рендеринг изображений)) на рабочем сервере, который, как оказалось, запускает Lucee, и заметил медленную производительность.

Ответ 1

Математика Integer медленнее, чем математика с плавающей запятой, поэтому она работает медленнее из-за того, что Lucee сохраняет переменные как типы. если вы вынудите n не целого числа, Lucee работает быстрее на 4 раза

if ((n+1.0) % d == 0) {

Эта настройка также более чем удваивает скорость в ACF.

https://luceeserver.atlassian.net/browse/LDEV-1541

Ответ 2

Я думаю, что проблема с производительностью связана с тем, что Lucee исправляет, а не вы и ваш код.

Однако с точки зрения общей производительности этого конкретного алгоритма, наилучшей экономией, которую вы можете сделать, является цикл до sqr(n)+1, а не весь путь до n. Вы делаете больше работы, чем вам нужно, и это больше влияет на производительность этого кода, чем на различия в платформе.

Также вам нужно только перебрать предыдущие простые числа, а не каждый (второй) номер. Это улучшит вашу производительность.

Я понимаю, что алгоритм - это всего лишь пример, но, честно говоря, остальная часть этого не может быть исправлена. Поднимите билет с Lucee и дождитесь его фиксации (или DIY, если у вас есть время/знание Java).