Constantin Tsukanov

var twoPoints = document.getElementById("twoPoints").textContent;

Но вообще, у вас всё очень плохо: вы сразу же перезаписываете содержимое блока #time (и больше никакого #twoPoints вы в документе не найдёте), а что происходит в setTimeout я вообще не понимаю.
Должно быть хотя бы так: https://jsfiddle.net/ryohL5bv/1/

replaceOne по сути тоже самое что и updateOne, только на updateOne стоит защита, чтоб не перетереть весь документ, т.е. обязательно должен быть $set или $addToSet или т.п. на replaceOne нет таких ограничений

Сделал подобный туториал, где разбираются и асинхронные запросы тоже. Буду рад если помогу - https://www.gitbook.com/book/maxfarseer/redux-cour...

1. Проксировать трафик через nginx (инструкции в гугле)
   
2. Настраивать защиту от DDOS (и еще много всего полезного) в nginx (инструкции в гугле)
   
3. Профит)
   

Примерно так:

var http = require('http');
var ipTables = {};

var server = http.createServer((req, res) => {
    //Ваш обработчик запроса или express/connect вместо него
});

server.on('connection', socket => {
    var ip = socket.address().address;
    var time = Date.now();
    if(ip in ipTables) {
        if(time - ipTables[ip].time > 3000) {
            ipTables[ip] = {
                count : 1,
                time
            };
            return;
        }
        ipTables[ip].count++;
        ipTables[ip].time = time;
        if(ipTables[ip].count > 100) {
            socket.end('HTTP/1.1 429 Too Many Requests\n\n');
            socket.destroy(); //Обрываем соеденение, так как ip ломится слишком часто
        }
        return;
    }
    ipTables[ip] = {
        count : 1,
        time
    };
});

server.listen(80);

Отвечать на этот вопрос без какой-либо дополнительной информации - это как гадать на кофейной гуще. Какой CPU - если это древний Pentium D с допотопным конвейером и глупыми регистрами - одно дело, а если это новейший Core i7 на Haswell - другое. Что до настроек - вот честно, "стандартные" вообще ни о чём не говорит. Я уже не говорю, что было бы не плохо указать количество опытов с максимальным и минимальным - вполне возможно глупые ОС с планировщиком как-то неудачно распределяют время. Любой ответ, который можно тут указать может быть техническим грамотным, но совершенно не соответствующий истине.

Рискну предположить такой расклад - об оптимизациях мы почти ничего не знаем и делаем "стандартную" дебаговую сборку. В этих случаях транслятор вставляет в код специальные метки, по которым можно будет сопоставить инструкции с файлом и номером строки. Понятное дело, что в объектные файлы попадут и холостые циклы и бесполезные разыменования. Ни о каких кэшированиях или перестановках не может быть и речи - что попросили, то получили.

Теперь давайте вместе подумаем о том, какие различия между x86-64 и x86. На самом деле, вопрос поставлен не очень корректно - x86-64 почти полностью включает в себя x86. Из изменённого - размер указателя (адреса), да немного переделана логика регистров (хотя все они на месте, просто добавилось ещё лишние несколько десятков) - теперь часть аргументов в функцию передаётся через дополнительные регистры, тогда как в x86 все идут через стек. Однако получить здесь преимущество не так уж и просто - процессор тоже не дурак, в случае линейной обработки информации (или любая длительная работа с небольшими участками памяти) он прекрасно всё кэширует и работа со стеком в общем случае не сильно медленнее работы с регистрами.

Теперь смотрим на код. Что там? Куча адресной арифметики, немного функций, да и аргументов почти нет. 8 миллионов слов? Не думаю что рекурсия вынудит вылезти стеку за пределы кэша, так что есть подозрение о паритете архитектур в данном случае. Однако большое количество адресной арифметики и увеличенный размер адреса в битах... во сколько раз? В два раза?

Ну да ладно, ясное дело, сложение реализовано за 1 такт. Скорее всего. Конечно, здесь вопрос процессора, но даже узнав модель будет сложно узнать наверняка, разве только синтетическим тестом (много раз обращаться по адресу - сумме двух случайных чисел). Да и Windows 8.1 никогда не был стандартом производительности (скорее с точностью наоборот), и VC++ никогда не был лучшим компилятором.

Попробуйте gcc (меня разве только интересует откуда на Windows взялся gcc) с флагом -O3. И посмотрите машинный код для 64 бита и 32 бита (можно пользоваться objdump из binutils или посмотреть машинный код в IDE Visual Studio - точно расположение кнопки не помню, но можно поискать в менюшках). Скорее всего причина не одна, их множество. Так, вызов функции сопровождается сохранением контекста, тогда как в x64 регистров больше, больше и контекст. Собираем такие моменты по крупицам... Вот и получаем.

P.S. Давным давно, разговаривал с преподавателем. Простая перекомпиляция под 64 бита ускорила код на 30%. Это был колхозный кодек, немного похожий на libx264 (от туда была сдёрнута часть кода). Естественно, проект собирался со всеми оптимизациями, со всем расширениями инструкций - со всем, чем можно. И сборка под платформу x86-64 (с SSE, MMX, FMA и прочие). Жутко наукоёмкий разношёрстный код (писали все - от зелёных аспирантов, до ровесников Страуструпа и профессоров университета) - туева хуча функций, структур, объединений и очень, очень много параметров, многие из которых передают в аргументы функций. Ну и целевая платформа - жутко порезанный и переделанный Windows Embedded - там просто не чего было планировать.

Я не уверен, но скорее всего, повлиять на это нельзя со стороны сайта.
И как совет - отключай эффекты появления, параллакса и прочие визуальные эффекты для мобильных и планшетов. Не те это устройства, в которых можно безболезненно показывать это все. Оставляй красивости для десктопов, а в мобильных делай упор на быстроту загрузки и работы сайта. И надо проверить еще 100vh на айдевайсах! В последний раз там была проблема у меня с этим.

Cordova