Nick Sdk

не подойдет.
профит получите только в более резвом ui системы (такой же результат можно получить и при отключении красивостей). на работе самих проектов он не скажется никак.
и этот профит совершенно не стоит денег за egpu.

вот если бы вы занимались задачами для gpu, тогда смысл и был бы.
хотя для таких задач лучше пользовать НЕбуки.

Имхо, бесполезная метрика. Давайте разберёмся почему.
Что нам даст данная метрика? Ничего. Бизнес-логика и сетевые издержки съедают куда больше и на их фоне производительность движка даже не заметна. А если вспомнить что проект состоит не только из кода так вообще смешно становится

В текущий момент поддерживаю достаточно большой проект на фалконе, который был написан до меня. Так вот, всем кто там дрочил на сишные либы фалкона, мое вам имхо, основаное на годе поддержки этого проекта:

1) Оно мегахреново переносится и очень криво становится на свежие системы. Корме того что половина гайдов по установке устарела, но все еще лежит на оф. сайте, гайды сообщества противоречат друг-другу, 90% из них не работает, а про некоторые дистрибутивы можете просто забыть, там они работать просто не будут.

2) Оно все работает as is и хрен ты посмотришь как работает родная вьюшка/конторллер "внутри", а доки не сказать чтобы хорошо описаны, комьюнити слабенькое, многие вещи сделаны спорно, а поправить или что-то подкрутить дело неблагодарное.

3) Теперь про самое интересное - скорость работы. Так вот, вся это мутотень про память и прочие плюшки на нормальном сервере не ощущается вообще, то есть переходя определенный предел мощности/вооруженности сервера скорость практически сравнялась с нативом (использовался ларавел и Уии на том же сервере, по замерам - плюс-минус то же по скорости, и чуть больше по памяти (центос, 64гб оперативы, 4 проца, нжинкс, пхп 7.2). Короче выгода была на ветке пхп 5.+, сейчас его актуальность практически равна нулю.

4) В моем случае по приходу сервер регулярно падал при "серьезной" нагрузке (20-30рпс), в чем я изначально предположил вину старых модулей фалкона, но по факту оказалось что 99% нагрузки вносили ожидания запросов к бд, некоторые из которых были по 7-15 минут, а некоторые куски кода создавали по 80+ запросов с 1 страницы, просто дозапрашивая какие-то данные для вьюшки в цикле. Предыдущий "кудесник" кормил руководство отмазками типа - "мало памяти, железо слабое, все плохо, а то бы летало...". "Магия плохого железа" закончилась после оптимизации запросов и доведения самых тяжелых до 0,5 секунды, а так же выборки всех данных в 1-2 запроса с нормальными джоинами.

5) Основной вопрос всегда сводится к жадности - взять что-то побыстрее из софта, сэкономив на хостинге/оборудовании. И оно всегда не работает так, по ряду факторов, которые достаточно очевидны.

если вам не нужны возможности шторма, то и платить за них смысла нет.

шторм выигрывает хотя бы тем, что он готов для работы изкаробки, а не после длительной обработки напильником.

хотите ещё примеров? их есть у меня:
покажите мне в всц такой же рефакторинг как в шторме.
покажите мне в всц автокомплит для фабричных методов.

этот список можно продолжать долго.
а можно (и нужно) самому попробовать и выбрать.

Сам нашел уже ответ. Видно на скрине что нужно сделать - может пригодится кому.

Deployment -> Excluded Paths

так на локалке хочу сравнить два файла ,для этого надо перевети код в один вид

Дык там настройка есть


А вообще замена \n\n на \n внезапно заменит двойные переводы строк на одинарные.

Очень сложных проектов на Yii2 с открытым, да ещё и хорошим кодом очень мало)) Прежде всего, потому что Yii создан для быстрой разработки нарушая все правила сложных архитектур. А учитывая его устарелость, то тем более таких проектов мало. На форуме давно обсуждался этот вопрос. Там есть ссылки на проекты и код. Так же на сайте yiipowered.com есть список проектов, у некоторых с исходным кодом.

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

Если по теме, то начните изучать или искать DDD, CQRS, SOA, Микросервисы. В принципе это основные архитектурные подходы в разработке. На Yii по DDD есть хороший пример. Однако начинать НОВЫЙ проект на Yii2 используя даже самую сложную архитектуру - путь в никуда. Yii2 создан для других целей. Чтобы понять можно посмотреть ответ на вопрос: Актуален ли Yii2 Фреймворк в 2020?

Тут много нюансов и ответить однозначно сложно. Как уже написал Иван Шумов фреймворк - это инструмент. Каждый инструмент подбирается под конкретную задачу:

• СMS - система управления сайтом (Wordpress, Joomla и т.д.). Создан для простого и удобного управления сайтом (контентом). Как правило, доступен для работы простому пользователю, без знания языков программирования. Подойдёт для: простых сайтов, блогов, там где не требуется нагрузка и безопасность.
  
• RAD framework (Yii2) - фреймворк для быстрой разработки. RAD Фреймворк имеет, монолитную и связанную архитектуру. Он является антипаттенрном и позволяет вам делать всё что угодно, лишь бы вы быстро собрали свой проект. (Используется паттерн Table First - спроектировали базу и по схеме сгенерировали модели данных). При этом Вам никто не говорит, что он не может использоваться для серьёзных проектов. Например, DNS..
  
• Компонентные фреймворки (Symfony, Laravel). Это фреймворки, которые разделены на независимые компоненты, которые вы можете подключать к своему проекту при необходимости. В самом фреймворке заложен только необходимый минимум, а всё остальное вынесено в компоненты. Эти компоненты могут использоваться (или не использоваться). Могут использоваться для другого фреймворка (сам Yii2 использует компоненты симфони). Doctirine, которая позволяет вам забыть о базе данных и сосредоточиться на коде. Фреймворк задаёт вам некий стиль, некую структуру и типизацию и требует более хорошего и обдуманного кодинга. Например, при использовании twig вы не сможете сделать запрос в view. Чего нельзя сказать про Yii. Вы там можете построить хорошую бизнес логику, что и встречается...
  
• Микрофреймворки (Slim). В таких фреймворках заложен самый минимум, а всё остальное программист должен искать или писать самостоятельно, выстраивать свою архитектуру приложения. Он легкий и простой. Кто-то и Symfony относит к микрофреймворкам. Тут меня многие могут упрекнуть. Подойдет для очень простых, гибких, легких приложений, например, микросервисов. Фреймворк не задает вам никаких правил и архитектуры. Вы должны сами продумать все детали приложения. Где-то используете twig, где то Data Mapper, где-то ActiveRecord. Для работы с таким фреймворком требуется много знаний и опыта. Так как вам всё придется делать самому. Здесь за вас никто не подумал.
  

Что же для чего выбрать?
Решать вам исходя из конкретной задачи. Здесь нет понятия хуже/лучше. Чтобы что-то выбрать нужно на каждом попробовать собрать пару проектов. Тогда и будет понимание когда и что выбирать. Это как автомобиль. Какой лучше BMW или LADA? Оба автомобиля, но каждый для своей аудитории, по своим потребностям, для своих задач.

Почему другие говорят что Yii2 плохой?

• 2 версия морально устарела. Это не значит что ВЕСЬ фреймворк плохой, просто им давно никто не занимался. Сейчас идет разработка Yii3, которая многократно лучше 2 версии, но 3 версия доступна только в демо. Поэтому, если хочется писать НОВЫЙ проект на Yii, то я бы не стал выбирать 2 версию. Можете подождать Yii3, но никто не знает когда будет релиз. Можете начать писать используя Yii3-demo, но там может всё поменяться к моменту релиза.
  
• Он монолитный. Если вам требуется сделать проект используя много приложений с разными компонентами, то пойдёте по пути Advanced шаблона, где каждое приложение будет папкой: backend, forntend, console. Однако при большой нагрузке вам потребуется разносить приложения. Тогда ваш core будет дублироваться во всех приложениях. Там будет то, что вам даже не требуется. Потому что Yii2 монолит.
  
• В Yii2 используется Actvie Record. AR - это не плохо. Его многие любят, многие ценят и хвалят. Но для больших проектов он предоставляет неудобства. Например, при изменении поля в базе данных - приходится менять все свойства и надеяться что везде поменяли, так как в GrigView используется магия, при получение значений из модели 'value' => 'profile.last_name'. Так же нельзя сделать свойства модели (сущности), приватными. Из-за чего состояние модели можно изменить где угодно и вы никак не проконтролируете это.
  
• Много абстракции, которую не распознает редактор. Например, вы можете вызвать в контроллере Yii::$app->user->id. Вам приходится делать докблок, что User это common/auth/Identity, а не yii/web/User
  

Ну и так далее. С каждым из этих пунктов можно бороться, при правильном подходе. Как уже сказали в плохих руках любой код может пахнуть. Но это основное. Надеюсь, меня не раскритикуют другие за спорные моменты. В таких вопросах всегда есть разногласия) Думаю, что смог донести в сжатом виде отличия.

Я думаю, самым разумным решением будет писать эти массивы в базу и сравнивать простым запросом. Именно так в общем случае решается задача "сравнение двух больших массивов данных на РНР." Конкретную же реализацию можно будет предложить только если будет конкретный вопрос, без "может быть " и "например".

Да, память в БД тоже не бесплатная, но тут надо уже определиться - или мы хотим ворочать гигазы варезов, или сидеть на копеечном впс с 500 метрами памяти. Одновременно не получится.

Можно конечно извернуться и скомпилить специальное расширение, которое как раз и предназначается для работы с иллимонами элементов, но опять же - все зависит от возможностей и потребностей.

Для начала вычислите смещение и длину для всех интересующих данных. Для конвертации достаточно функции parseInt
Если вам нужен заголовок, например

const headerHex = data.substring(0, 2) // получаем фрагмент, в котором содержится заголовок
const header = parseInt(headerHex, 16) // переводим в десятичную систему

Вариантов много. Из простого:

• по User-Agent
  
• по IP адресу через отслеживание количества запросов с одного адреса
  
• по используемым публичным прокси (многие такие сервисы явно сообщают, о себе кто они)
  
• и т.д.
  

Из сложного:

• отслеживают перемещение мыши
  
• ведут аналитику на о типичных поведениях пользователя и ищуют анамалии
  

Если начинают банить прямо с самого первого запроса, значит спались на чем то элементарном и примитивном. Потому что при сложных вариантах защиты для сбора аналитики боту дают по сайту походить.

Алексей очень хорошо описал причины, которые подтверждаются некоторым личным опытом.

Очень часто, в логах сервера, в user-agent можно встретить selenium. Достаточно в конфиг прописать правило отклонения запросов с user-agent: (*selenium*) и проблема исчезает.

Также, те, у кого стоит метрика, могут обнаружить посетителей, которые ничего не делают, после чего отправляют ip в бан руками.

Обходить это, можно загружая страницу через браузер и случайно сдвигать мышь, случайное количество раз (от 5-10), через случайные промежутки. Спасет от ручной проверки, для большинства сайтов.

Для 100% гарантии, чтобы не банили, нужно "наводиться" на ссылки, которые нужно распарсить следующими (по очереди). Однако, в этом случае, вы пожертвуете производительностью парсера.

Как реализовать: Поднять сервис (несколько) на машине с vnc и получать страницу через браузер, имитируя работу мышкой.

Но, обычно, указать корректный user-agent достаточно. (Я, почему-то уверен, что вы остановитесь на этом варианте).

Однако, самым примитивным способом отследить, что твой сайт парсят, является мониторинг нагрузки сайта на сервер. Дело в том, что подавляющее большинство сайтов находиться на виртуальном хостинге, где владельцу сайта, сдается в аренду часть вычислительной мощности сервера.

Владельцу сайта проще заблокировать тот ip, с которого сыпятся запросы, чем проводить оптимизацию кода сайта и выяснять, по какой причине вообще создалась нагрузка (например, из-за не проставленных индексов в бд).
А порой, это является единственным вариантом, т.к. на сервер, может прилететь за час свыше 10000 запросов к сайту с одного ip.
Для сравнения от yandex/google, за сутки, может прийти около 4000 запросов (с минимальными настройками индексации).

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

раз и навсегда вообще не получится: кто–то любит два пробела, кто–то четыре, а кто–то табы.
я предпочитаю таб в четыре пробела. и это никак не мешает мне работать с людьми, которые имеют другие предпочтения.

Сама идея появилась от того, что при циклировании питания, изнашивается HDD и в гораздо меньшей степени, конденсаторы в цепях фильтрации питания.

Так что если исключить из рассмотрения HDD (его нет) и конденсаторы (там теперь кругом твердотельные), пробоем с циклированием нет никаких.

Идея о том, что частая гибернация может испортить SSD - также устарела, современные SSD и не такое переживут и будут заменены раньше - просто потому, что станут вмещать мало данных.

Добрый день

Написал два скрипта с замером времени поиска.

Search by object

let obj = {}

for(let i =0; i<1000; i++){
    obj['i'+i]=i
}

console.time('time')
for(let i =0; i<1000; i++){
const objResult = obj['i'+i];
}
console.timeEnd('time')

time: 0.156982421875ms

Search by array

let obj = []

for(let i =0; i<1000; i++){
    obj.push('i'+i)
}

console.time('time')

for(let i =0; i<1000; i++){
    const arrResult = obj.find(el => el === 'i'+i);
}
console.timeEnd('time')

time: 32.946044921875ms

Время конечно может отличатся, но в целом видится что поиск по массиву работаем медленнее обращения по ключу, по крайне мере в промышленном масштабе.