На самом деле сборка DLL библиотеки в cmake сводится к двум строчкам
CMAKE_MINIMUM_REQUIRED (VERSION 2.6)
ADD_LIBRARY(randomLibName SHARED one.c two.c three.c)
sim3x: кстати да... а я уже совсем забыл что он на golang тоже уполз.
В любом случае я сяду летом штопать порт golang'а под JVM, возможно даже сагитирую Дмитрия Вьюкова... так что будет ещё веселье в нашем детсаду.
nepster09: не мне решать зачем это нужно делать. Ничего не мешает координаты и названия которые определило geoip ложить в сессию пользователя и не дёргать каждый раз geoip и/или геокодинг/геолокацию гуглокарт.
В геолокации google используется банальный W3C Geolocation стандарт: GPS есть - жизнь удалась, GPS'a нет - получаем позицию ближайшего пограничного маршрутизатора вообще в другом городе.
Нет, правильно записывать IP пользовательского запроса и по нему получать координаты город/улицу, потом можно использовать эти координаты в рамках гуглокарты и по потребности получать прочую информацию геокодинга.
sim3x: потому что в JVM время компиляции на много больше и соответственно период повторного прогона тестов выше, в том же Goconvey можно гонять тесты каждые 1-3 секунды. В gradle с демоном на тот же самый объём тестов и исходников уходит в среднем 7-15 секунд, не учитывая времени выполнения самых тестов которое обычно происходит довольно медленно.
OpenGL - это не библиотека !
Сама библиотека в которой реализован интерфейс OpenGL поставляется с драйверами под вашу видеокарту.
И тут вряд ли кто-то сможет заванговать как и почему у вас оно где-то не определяется.
Да, в принципе можно взять тот же Phalcon, нормально кэшировать запросы в БД и не заморачиваться. Если у вас модель БД "черезодноместо", а так оно бывает у 80% людей которые задают подобные вопросы, то тут никакой фреймворк/язык/законы вселенской магии не помогут вам сделать ваш сервис быстрее - нужно было нормально организовывать работу и проводить QA.
Виктор Ablebeam: если в двух словах - проблемы будут.
Я понял - речь была о вертикальном масштабировании со стороны Ruby.
Нет простым vfork'ом и тонной воркеров тут проблему не решить.
1 запрос <=> 1 воркер/поток в одном процессе - путь в ад. Просто адовые накладные расходы на создание воркеров/потоков и довольно большой overhead по блокировке и переключению контекстов - обычно люди забывают что и в ОС тоже есть свой шедуллер, и он влияет :).
Много запросов <=> (количество ядер * 2) воркеров/потоков в рамках одного процесса- обычно оно так и делается, желательно в рамках какой-то producer-consumer модели типа disruptor или модели актёров аля akka, erlang, golang, greanlet'ы и т.п. Самопальные disruptor'ы проще контролировать и оптимизировать расходы памяти.
Есть ещё такие вещи как pfRing и netmap, и offheap кэширование - ну вот банальный redis vs terracota это 50 к 1 по скорости обработки fetch'a с хэш-таблицы. Когда микросервисные архитектуры делают через "одноместо", то подобные оптимизации абсолютно бесполезны и часто просто напрочь убивается вертикальное масштабирование... но тут уже речь идёт о трафике формата одноклассников или stackoverflow.
Виктор Ablebeam: я всегда считал в ноде должен быть какой-то встроенный disruptor, или хотя бы подобие планировщика, сам не ковырялся, но если там действительно такого нет - это просто прискорбно. Hail To the Golang.
Виктор Ablebeam: на 17К запросов вэбсерверы типа nginx помирают только если их неправильно готовить, да и на 17К запросах они бывают вовсе ненужны. Ну не зря же сейчас достаточно много проектов на рельсах слезли на golang и уменьшили количество своих серверов в 4-5 раз, а в случае с typesafe stack и Amazon'ом получилось в 8, хотя там это напрочь убило RAD.
._.
Нода как-бэ асинхронная, но потом она всётаки синхронная... и это влияет на производительность.
Берём профилятор и смотрим что где и как блокируется, а то блин звучит реально тупо...
Ещё тупее утверждать что каждый поток блокируется на время запроса к БД - это уже зависит от криворукости разработчиков самого драйвера и разработчиков приложения, как никак Unit Of Work никто не отменял.
Даже в случае с той же Java ЛЮБОЙ запрос в бд синхронен, и не важно сколько асинхронных обвёрток вокруг JDBC налепят - всеравно поток будет блокирован на время выполнения запроса, просто потому что асинхронного JDBC тупо нет в природе. И так сложилось исторически, и это отнюдь не означает что это решение не оптимально и что всё что "блокирует поток" заставляет ваш процессор простаивать, это очень глупый предрассудок дилетантов.
Ну вот к примеру в golang'е достаточно новый и стабильные драйвер lib/pq написан синхронным не потому что это "неоптимально", а просто по привычке и с пониманием того что в ядре ОС тоже есть свой планировщик, и что если нужно то он тоже не будет зря щёлкать процессорные такты, напротив тут приветствуется использование unit of work.
www.cmake.org/Wiki/BuildingWinDLL
На самом деле сборка DLL библиотеки в cmake сводится к двум строчкам
CMAKE_MINIMUM_REQUIRED (VERSION 2.6)
ADD_LIBRARY(randomLibName SHARED one.c two.c three.c)