Насколько в действительности возрастает нагрузка, если писать код, разбивая все на отдельные действия?

Question

[Серж Ткач]

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

=== Вариант 1 ===
Все действия отделены друг от друга
Легко читать
Легко делать отладку, так как всегда можно просто взять и вывести $price на экран
Но для выполнения скрипта (особенно, если таких мест много), требуется больше памяти

foreach ($this->cart->getProducts() as $product) {
              $price = get_product_price_without_sale($product['product_id']); // Значение получено заранее. Оно хранится в памяти и занимает лишнее место
              $data_deal['products'][] = array(
                    'name'     => htmlspecialchars($product['name']),
                    'count' => $product['quantity'],
                    'price'    => $this->currency->format($price, $order_info['currency_code'], $order_info['currency_value'], false)
                );
            }

=== Вариант 2 ===
Труднее читать
Для отладки нужно более внимательно копировать конструкцию, которая покажет, что там у нас получается
Память не занимается промежуточными переменными

foreach ($this->cart->getProducts() as $product) {
              $data_deal['products'][] = array(
                    'name'     => htmlspecialchars($product['name']),
                    'count' => $product['quantity'],

                    'price'    => $this->currency->format(get_product_price_without_sale($product['product_id']), $order_info['currency_code'], $order_info['currency_value'], false)
                );
            }

Comments

[Денис Загаевский]

Память не занимается переменными? Waat? Что за бред вообще?

[Yustas Alexu]

Денис Загаевский: промежуточными

[Денис Загаевский]

Yustas Alexu: Угу. Переменными.

Answer 1

[Saboteur]

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

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

Comments

[MrShaggy]

Все верно! Хочу еще добавить, что докупить железа порой дешевле, чем переписать проект из-за плохого кода.

Answer 2

[Falseclock]

Вы мыслите в правильном русле.... но все еще далеко от совершенства.

каждое действие должно делаться в одном методе (функции для PHP)

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

<?php
// хендлер реализаций
class WaybillHandler
{
	protected $debug	= true;

	protected $db		= null;
	protected $socket	= array();
	protected $structure= array();
	protected $doc		= null;
	protected $crmData	= array();
	
	public function __construct($waybill)
	{
		$this->db = DBPool::me()->getLink();
		$this->doc = $waybill;
		
		self::Handler();
	}
	
	private function Handler()
	{
		$db = $this->db;
		
		// Если реализация не привязана к счету, то ничего не делаем
		if ($this->doc['ДокументОснование']['#type'] != 'jcfg:DocumentRef.СчетНаОплатуПокупателю') {
			return;
		}
		
		$this->structure = Utils1c::prepareStructure($this->doc,'waybill');
		
		// Усли реализация поставлена на удаление, то автоматически будет отменена проводка
		// либо мы вручную убрали проводку, а значит мы должны удалить запись из CRM
		if ($this->doc['Posted'] == false) {
			$this->structure['debug'][] = "Реализация не проведена, делаем попытку удаление данных"." (".__LINE__.")";
			self::deleteWaybillFromCRM();
		} else {
			if (self::isRelatedToOurInvoice()) {
				self::findDataFromCRMforWaybill();
				if (count($this->crmData)) {
					self::deleteWaybillDataOnDeleteInERP();
					self::insertMissingWaybillDataToERP();
					self::compareWaybillDataBetweenCRMandERP();
				} else {
					self::insertWaybillDataOnNewRowInERP();
				}
				self::updateStructureFinally();
			} else {
				$this->structure['debug'][] = "Мы не нашли связь между этой реализацией и счетами в CRM"." (".__LINE__.")";
			}
		}
		if (!$this->debug) {
			$this->structure['debug'] = array();
		}
		$this->socket[] = Driver1c::SOCKET_MARKER.json_encode($this->structure, JSON_UNESCAPED_UNICODE);
		
		new WebSocketClient($this->socket);
		
		return;
	}
}

Comments

[Falseclock]

сразу хочу сказать, что мой код не может быть априори самым правильным и самым лучшим, но негласные правила требуют, чтобы ваш код был понятен другим и зачем вы это делаете. Даже для самого себя лучше комментировать код и делать его понятным, чтобы завтра кто-то мог понять весь алгоритм и последовательность действий. Я даже SQL запросы имею привычку комментировать

$std = $db->prepare("DELETE FROM vatinvoice_data WHERE item_uuid = ? AND vatinvoice_uuid = ?");
			
			// раз удалили данные, то надо вернуть состояние для тех order_data_id, для которых удалили данные
			// вытаскиваем 
			
			$sts = $db->prepare("
				SELECT
					id.quantity AS quantity_invoice               -- количество по инвойсу
					SUM(wd.quantity) AS quantity_waybill,         -- вытаскиваем сумму из всех реализации
					SUM(vd.quantity) AS quantity_closed           -- суммируем количество из СФ
				FROM
					vatinvoice_data vd                            -- вытаскиваем данные из СФ
				JOIN vatinvoices v ON                             -- прикручиваем сам СФ по vatinvoice_uuid
					v.vatinvoice_uuid = vd.vatinvoice_uuid
				JOIN waybill_data wd ON                           -- прикручиваем данные из реализации
					wd.waybill_uuid = v.waybill_uuid
				JOIN invoice_data id ON
					id.item_uuid = 
				WHERE
					wd.item_uuid = ? AND
					wd.waybill_uuid = ?
				GROUP BY
					id.quantity
			");
			
			$stu = $db->prepare("UPDATE order_data SET status = ? WHERE order_data_id = ?");

[Sergej]

Falseclock: SQL запросы - сама по себе, плохая привычка.

[Falseclock]

Doc: объясните пожалуйста

[Серж Ткач]

Doc: Мне тоже интересно!

[Sergej]

Falseclock: Серж Ткач: Все очень просто.
Представьте у вас десятки а то и сотни запросов.
Вы думаете нормальный разработчик будет ковыряться в них?
Ответ: нет.
Я SQL код не видел уже года 3 в глаза))

Намного проще оперировать объектами. Использовать туже Doctrine или Spot и т.д.
У вас есть маппинг, есть модель и какой то парам-конвертер.
В коде вы оперируете исключительно объектами PHP и ни какого SQL.
Если что то требуется изменить, меняете маппинг и если того требует задача, дорабатываете модель.
Соответственно стоит использовать CommandBus и желательно подход DDD.

Это вас избавит от любого намека SQL

[Falseclock]

Doc: ха ха... рассмешили.... вы мыслите на уровне кодеров, которые штампуют веб сайты визитки...

вы видимо не решали задачи промышленного масштаба, не сталкивались ни с рекурсиями, ни с динамическими триггерами, ни с сопоставлениями, ни с преобразователями, и даже с запросами, под типа такого, который я уверен не сможет сформировать ни доктрин, ни спот ни что бы то ни было другое. Все эти игрушки придуманы для детишек, которые не отличают LEFT от RIGHT джоинов. Например этого

SELECT 
				year,
				CASE WHEN jan IS NULL THEN 0 ELSE jan END,
				CASE WHEN feb IS NULL THEN 0 ELSE feb END,
				CASE WHEN mar IS NULL THEN 0 ELSE mar END,
				CASE WHEN apr IS NULL THEN 0 ELSE apr END,
				CASE WHEN may IS NULL THEN 0 ELSE may END,
				CASE WHEN jun IS NULL THEN 0 ELSE jun END,
				CASE WHEN jul IS NULL THEN 0 ELSE jul END,
				CASE WHEN aug IS NULL THEN 0 ELSE aug END,
				CASE WHEN sep IS NULL THEN 0 ELSE sep END,
				CASE WHEN oct IS NULL THEN 0 ELSE oct END,
				CASE WHEN nov IS NULL THEN 0 ELSE nov END,
				CASE WHEN dec IS NULL THEN 0 ELSE dec END
				
			FROM CROSSTAB
			(
				'SELECT
					EXTRACT(YEAR FROM invoice_date) AS year,
					EXTRACT(MONTH FROM invoice_date) AS month,
					SUM(invoice_amount) / 1000 AS qty
				FROM 
					invoices
				WHERE
					invoice_date > invoice_date - interval ''4 year''
				GROUP BY
					year,
					month
				ORDER BY 
					year DESC',
				'SELECT m FROM generate_series(1,12) m'
			) AS (
			  year INT,
			  jan NUMERIC,
			  feb NUMERIC,
			  mar NUMERIC,
			  apr NUMERIC,
			  may NUMERIC,
			  jun NUMERIC,
			  jul NUMERIC,
			  aug NUMERIC,
			  sep NUMERIC,
			  oct NUMERIC,
			  nov NUMERIC,
			  dec NUMERIC
			) ORDER BY year DESC
			LIMIT 3

[Sergej]

Falseclock: Возможно вы и правы. Я всего лишь делал butik.ru, банковскую ORM (финансовые проводки, дебет, кредит и касса (tempbank)), брокерскую систему (заказы по всеми миру в горячем режиме), букинг проекты (это самые тяжелые системы в сети).

Веб-сайты в обычном понимании я не делаю уже 3 года точно.

Начнем с того, что вы предоставили простейший запрос в первом комментарии.
Теперь вы показали запрос, который при 100 итераций повесит БД. Что уже не верно.
Проще как в БД реализовать функцию под такую задачу (чем должен заниматься архитектор БД).
Но и в ORM данная конструкция реализуется спокойно (в смысле без костылей). Но лучше сделать с expand интегрировав объекты под каждый тип, так быстрее будет обрабатываться.
Такое ощущение, что вы показали какой то сложный запрос и пытаетесь этим гордиться.

[Falseclock]

Doc:

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

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

Теперь вы показали запрос, который при 100 итераций повесит БД. Что уже не верно.

этот запрос на самом деле просто переворачивает результат выборки из вертикальной таблицы в горизонтальную для формирования графика. Ничего сложного и необычного. Просто пользователи не знают всех возможностей БД и не использует заложенный инструментарий. Этот как с MS Word, когда люди выписывают номера страниц вручную, когда есть колонтитулы.

Но и в ORM данная конструкция реализуется спокойно (в смысле без костылей). Но лучше сделать с expand интегрировав объекты под каждый тип, так быстрее будет обрабатываться.

мне кажется вы ошибаетесь. Зачем забирать процессорное время, создавать временные массивы, перебирать их, нагружать память лишним препроцессорным кодом, когда это может сделать БД за более короткий срок и с меньшей тратой ресурсов? У меня все руки не доходят сразу выводить в JSON строке эти записи, чтобы не нагружать препроцессор логикой и лишним кодом, так как эта выборка нужна именно в строчном варианте.

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

это один из самых обычных запросов в моей повседневной практике. Я пытаюсь заставить БД работать на все 100% что она умеет. Умеет работать с JSON и делать выборку в нем? Круто. Менять значение в отдельных полях XML записи? Круто! Нафига выгружать данные из базы, менять их и снова апдейтить, когда сделать можно инструментами самой базы?

Я разрабатывал базы для крупнейшего мобильного оператора в КЗ и знаю что такое нагрузка и масштабируемость. 1 лишнее движение на стороне препроцессора выливается в тормоза всей системы. Поэтому всегда проводятся бенчмарки, тесты и выбор оптимального решения. в 99% случаев проще отдать оперировать данными базе, она лучше умеет это делать, чем кто либо.

[Falseclock]

Doc: вот типичная статья, с тестами и бенчмарками, доказывающая, что выводить самой базой в JSON быстрее чем бы то ни было... ни perl, php или JS рядом не стояли. https://hashrocket.com/blog/posts/faster-json-gene...

Так что в топку Doctrine или Spot и т.д., Только хардкор! Ручками и головой!

[Falseclock]

Doc: специально переделал свой SQL запрос, чтобы он мне выдавал готовую строку в JSON. Сделал бенчмаркинг на 10000 запросов в цикле. топ не поднимается выше 0.7. При этом если выдирать просто данные обычным запросом и средствами PHP переделывать один в массив в другой - 95 циклов за секунду. И это я не прикручивал сторонние библиотеки, которые мне якобы помогут.
Если выдергивать средствами SQL готовую строку, то это 102 цикла в секунду. Разница маленькая, потому что объем данных мизерный - всего 4 строки и 12 колонок. Если выдергивать по 1000 строк и по 30 колонок в строке, то прирост уже более чем на 40%. В первую очередь потому что база работает быстрее чем препроцессоры PHP. Плюс ко всему не нужно выдергивать каждую строку, данные из оперативной памяти моментально высвобождаются и не надо загружать канал объемными данными из сокета.

Вот сам запрос:

SELECT 
	JSON_OBJECT_AGG
	(
		year, 
		JSON_BUILD_ARRAY(jan,feb,mar,apr,may,jun,jul,aug,sep,oct,nov,dec)
	)
 FROM (
	SELECT 
		year,
		CASE WHEN jan IS NULL THEN 0 ELSE jan END,
		CASE WHEN feb IS NULL THEN 0 ELSE feb END,
		CASE WHEN mar IS NULL THEN 0 ELSE mar END,
		CASE WHEN apr IS NULL THEN 0 ELSE apr END,
		CASE WHEN may IS NULL THEN 0 ELSE may END,
		CASE WHEN jun IS NULL THEN 0 ELSE jun END,
		CASE WHEN jul IS NULL THEN 0 ELSE jul END,
		CASE WHEN aug IS NULL THEN 0 ELSE aug END,
		CASE WHEN sep IS NULL THEN 0 ELSE sep END,
		CASE WHEN oct IS NULL THEN 0 ELSE oct END,
		CASE WHEN nov IS NULL THEN 0 ELSE nov END,
		CASE WHEN dec IS NULL THEN 0 ELSE dec END
		
	FROM CROSSTAB
	(
		'SELECT
			EXTRACT(YEAR FROM order_date) AS year,
			EXTRACT(MONTH FROM order_date) AS month,
			COUNT(order_id) AS qty
		FROM 
			orders
		WHERE
			order_date > order_date - interval ''4 year'' AND
			order_state = '?'
		GROUP BY
			year,
			month
		ORDER BY 
			year DESC',
		'SELECT m FROM generate_series(1,12) m'
	) AS (
	  year INT,
	  jan INT,
	  feb INT,
	  mar INT,
	  apr INT,
	  may INT,
	  jun INT,
	  jul INT,
	  aug INT,
	  sep INT,
	  oct INT,
	  nov INT,
	  dec INT
	) ORDER BY year DESC
	LIMIT 3
) data

А вот результат в единственной строке, которую мы получаем.

{ "2017" : [214, 88, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], "2016" : [119, 181, 194, 200, 170, 211, 179, 199, 233, 225, 205, 154], "2015" : [124, 130, 152, 187, 159, 164, 129, 116, 115, 119, 129, 106] }

Так что курят в сторонке ваши Doctrine или Spot. Пионер в данной области был Sybase BusinessObjects в начале 2000-х. И даже они не смогли сделать универсальный драйвер для запросов, потому что это не сколько трудно, а сколько затратно и не рентабельно жрать ресурсы сервера, когда нативным языком проще, быстрее и эффективней. Сдулись в конце 2000-х.