Только учитывайте, что для полноценной работы нужен еще TURN сервер (релей), потому что по статистике до 10% пользователей живут за NATом, который не позволит UDP hole punching.
А про p2p компонент лучше читать на сайте libjingle, webrtc использует именно его.
Перед тем как переписывать весь проект на С++, проще попробовать hiphop. Он позволяет ощутимо выиграть в производительности, не переписывая систему с нуля. У него навалом подводных камней (нет поддержки для разных новый фич php, нет многих модулей), но для больших проектов, на мой взгляд, это более адекватный выход.
У них там устаревшая информация, к сожалению, можете зайти из хрома сюда, например, и проверить. У меня завелось на стандартной версии без включения каких-либо флагов.
А у меня самая часто используемая команда — это ack
Есть прекрасная утилита huffshell, которая анализирует историю команд и советует какие алиасы создать, исходя из частоты использования.
Причем она учитывает всякие ключи при вызове, т.е. она предлагает 'ack' -> 'a', 'ack -i' -> 'ai' и т.д.
Как-то сложно, достаточно открыть страницу с видео, переключить на нужное разрешение и посмотреть во вкладке Developer Tools -> Network (Safari, Chrome) адрес, который упрямо продолжает загружаться, хотя вся страница уже готова. Скопировать его и скормить, например curl. Ну это если не надо скачивать видео в промышленных масштабах.
У Расмуса Лердорфа есть презентация PHP Performance, где он препарирует WordPress и показывает, что можно с ним сделать. В том числе с помощью HipHop for PHP.
По европейским меркам 290 € за жилье — это копейки. У меня знакомые учились в Париже, Мадриде и Делфте (Нидерланды), какую-то общагу предоставляли только Нидерландах и стоила она 400, а в Мадриде и Париже людям приходилось снимать комнаты (~400 и ~550 соответственно). При стипендии в 1100 или около того.
И да, те у кого нет связей могут попробовать через Erasmus Mundus, те самые знакомые уезжали именно по этой программе. Но там хорошо бы иметь высокий средний балл, TOEFL и грамотное мотивационное письмо.
Единственная проблема с этим плагином в том, что сниппеты идут в том же репозитории, что и плагин. Если использовать менеджеры пакетов (например, VUB, который писался под Pathogen), то надо форкать репозиторий, чтобы дописывать свои сниппеты.
Да, конечно, соглашусь «i << 1» это перебор, это скорее привычка так писать.
И про две строки матрицы — тоже хороша идея, мы не делали токого рада оптимизаций, потому что пока производительность нас устраивает.
> Плюс код не потокобезопасен.
Зачем использовать этот объект в нескольких потоках? Вы сэкономите совсем немного памяти и получите расходы на синхронизацию.
> Да и если вы используете soundex, то…
Мы совсем его не используем.
> 8 миллисекунд на запрос к базе из 2.5к слов — это пугающий результат. Масштабируемость у вас линейная и всего 312к слов дадут секунду на запрос.
Да, вы правы, но в нашем случае словарь не будет линейно расти с ростом числа заведений в базе и врядли достигнет такого размера.
Если уж словарь большой сперва можно воспользоваться n-граммным индексом.
Ну и конечно в коде много мест которые можно пооптимизировать, наподобии двух строк матрицы про которые вы написали )
А каким индексом вы пользовались при поиске по базе ДНК? У вас все влезало в память или кешировали часть данных?
Базовый словарь places и places-index формируется на основании описаний заведений которые забиваются руками.
places хранит данные которые мы возвращаем в качестве результатов, по сути мы по нему не ищем.
places-index формируется на основании кириллическоего и/или английского названия заведения + набора синонимов.
Каждую фразу (вариант названия) перед загрузкой в индекс мы пытаемся расширить так:
1. Если фраза содержит '-' (например му-му), то создадим два варианта — без '-' и с заменой на пробел.
2. Если фраза содержала русские символы то дополнительно создадим тринслитерированный вариант
например для му-му получим:
му-му => { муму, му му, mumu, mu mu }
Для кириллицы мы объединили только (а, о, у) и (е, и)
А про p2p компонент лучше читать на сайте libjingle, webrtc использует именно его.
Есть прекрасная утилита huffshell, которая анализирует историю команд и советует какие алиасы создать, исходя из частоты использования.
Причем она учитывает всякие ключи при вызове, т.е. она предлагает 'ack' -> 'a', 'ack -i' -> 'ai' и т.д.
StorageReview
AnandTech
« — Alt + ъ
» — Alt + Shift + ъ
И да, те у кого нет связей могут попробовать через Erasmus Mundus, те самые знакомые уезжали именно по этой программе. Но там хорошо бы иметь высокий средний балл, TOEFL и грамотное мотивационное письмо.
На демоноиде ratio 7.39, up 1.11TB proof
И про две строки матрицы — тоже хороша идея, мы не делали токого рада оптимизаций, потому что пока производительность нас устраивает.
> Плюс код не потокобезопасен.
Зачем использовать этот объект в нескольких потоках? Вы сэкономите совсем немного памяти и получите расходы на синхронизацию.
> Да и если вы используете soundex, то…
Мы совсем его не используем.
> 8 миллисекунд на запрос к базе из 2.5к слов — это пугающий результат. Масштабируемость у вас линейная и всего 312к слов дадут секунду на запрос.
Да, вы правы, но в нашем случае словарь не будет линейно расти с ростом числа заведений в базе и врядли достигнет такого размера.
Если уж словарь большой сперва можно воспользоваться n-граммным индексом.
Ну и конечно в коде много мест которые можно пооптимизировать, наподобии двух строк матрицы про которые вы написали )
А каким индексом вы пользовались при поиске по базе ДНК? У вас все влезало в память или кешировали часть данных?
places хранит данные которые мы возвращаем в качестве результатов, по сути мы по нему не ищем.
places-index формируется на основании кириллическоего и/или английского названия заведения + набора синонимов.
Каждую фразу (вариант названия) перед загрузкой в индекс мы пытаемся расширить так:
1. Если фраза содержит '-' (например му-му), то создадим два варианта — без '-' и с заменой на пробел.
2. Если фраза содержала русские символы то дополнительно создадим тринслитерированный вариант
например для му-му получим:
му-му => { муму, му му, mumu, mu mu }
Для кириллицы мы объединили только (а, о, у) и (е, и)