Насколько забивает память «const self = this» в методах классов?

Question

[Смотритель]

Приветствую. Нужна помощь специалистов!
Попробую описать на упрощенном примере request(), т.к. не знаю, как просто на словах описать =)
Оригинал кода по сути тут как бы и не разместить, т.к. это пока только алгоритмический функциональный вид.

Использование в функциональном виде:

let varName;
function result(body, ext) {
	varName = ext;
	...
};
function req(params, ext) {
	request(params, (err, req, body) => {
		result(body, ext);
	});
};

Использование в классовом виде:

class CLS {
	constructor() {
		this.varName = null;
	};
	...
	result(body, ext) {
		this.varName = ext;
		...
	};

	req(params, ext) {
		const self = this;
		request(params, (err, req, body) => {
			self.result(body, ext);
		});
	};
	...
};

Использование классов более оправданно, т.к. требуется наследование + классовые свойства (несколько объектов одного класса, каждый со своим состоянием и данными). Однако с учетом того, что потребуется довольно много методов с обратным вызовом смущает необходимость использования вставки const self = this;

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

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

Answer 1

[Алексей Ярков]

const self = this;
request(params, (err, req, body) => {
      self.result(body, ext);
});

А зачем тут self, если у вас стрелочная функция?

Comments

[Смотритель]

Если чуток подробнее прокомментируете, буду крайне признателен. Но разве можно обратиться через this к объекту класса? А если это будет не просто вызов request() а если это будет вызов метода другого класса? что-то вроде:

const self = this;
helper.method(params, () => {
	self.result(...);
})

Ведь если вместо self обратиться через this - то это будет вызов метода класса helper.
Или я чего-то не понимаю?

[Алексей Ярков]

Артем, почитайте чем отличаются обычные функции от стрелочных.

[Алексей Ярков]

helper.method(params, () => {
  self.result(...); // self не нужен, юзайте this
})

helper.method(params, function () {
  self.result(...); // с this будут проблемы, юзайте self
})

[Смотритель]

Алексей, спасибо за наводку, если не сложно, поправьте меня, если я неверно понял суть:

class CLS {
	constructor () {
		this.varName = null;
	};

	function result(body, ext) {
		...
	};

	function req1(params, ext) {
		helper.method(params, (body) => {
			this.result(body, ext);		// отработает корректно и вызовет CLS.result
		});
	};

	function req2(params, ext) {
		helper.method(params, function(body) {
			this.result(body, ext);		// попытается вызвать helper.result(...)
		});
	};

	function req3(params, ext) {
		const self = this;
		helper.method(params, function(body) {
			self.result(body, ext);		// отработает корректно и вызовет CLS.result, но нафига, если можно req1
		});
	};
	...
};

[Алексей Ярков]

Артем, все верно ))

[Robur]

helper.method(params, function(body) {
this.result(body, ext); // попытается вызвать helper.result(...)
});

попытается вызывать this.result, а что там у вас будет в this - только helper.method знает. Может быть что угодно вплоть до undefined, на котором все упадет.

Answer 2

[Константин Китманов]

Задачка на подумать:

class A {
    answer: null;
    constructor(answer) {
        this.answer = answer;
    }
}
const a = new A(42);
const b = a;
b.answer = 24;
console.log(a.answer); // что выведет? почему? сколько в памяти содержится экземпляров класса A?

Ну а вообще Алексей Ярков правильно написал, у вас там стрелочная функция и self вам нужен как рыбе зонтик.

Comments

[Роман]

Какието простенькие у вас задачи)

[Константин Китманов]

Роман, ну автору вопроса это, видимо, не очевидно, раз он такие вещи спрашивает:)

[Смотритель]

Да, это я уже понял "век живи - век учись" =)
Но все же, если использовать self - то насколько это будет кушать память?
Это уже скорее любопытство, т.к. навскидку не приходит в голову прямо необходимость его использования, если юзать стрелочные функции.

[Роман]

У меня есть вопрос поинтересней, хоть и не про классы.

Допустимо ли такое использование апострофов?

$('.table > tbody').append(
    `${json.result.map(n =>
        `<tr>
        <td>${n.id}</td>
        <td>${n.description}</td>
        </tr>`
    ).join('')}`
);

PS: навеяно этим вопросом )

[Константин Китманов]

Мало. ОС сейчас все 64-битные, то есть указатели тоже. Понятно, это не нативный код и скорее всего есть какой-то оверхэд, но тоже небольшой. Чтоб ответить точно — надо углубляться в исходники V8 или ставить эксперименты. Думаю, что это байты, а не килобайты.

[Константин Китманов]

Роман, видел этот вопрос:) Честно скажу, в спеках не смотрел, но в хроме работает, редакторы и транспиляторы не ругаются. А сафари -- это новый ие6.

[Роман]

Константин Китманов, я вот уже 2 часа спеки читаю и не могу найти ничего, что объясняло бы почему не возникает ошибки)

[Константин Китманов]

Роман, ну внутри ${} допустим любой валидный JS-код. `` являются валидным JS-кодом.

[Смотритель]

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

А Ваш вопрос, судя по записи, не то, чтобы не к месту, а слегонца из другой части - судя по примеру Вас волнует клиентский код, причем с использованием jQuery-фреймворка.

[Роман]

Артем, да да Вы правы, добавил я тут немного оверхэда, не обращайте внимания:)

Константин Китманов, кстати, нашел ответ:

spoiler

Вложенные шаблоны

Временами, вложить шаблон — это кратчайший и, возможно, более читабельный способ составить строку. Просто поместите внутрь шаблона с обратными кавычками ещё одни, обернув их в подстановку ${ }. Например, если выражение истинно, можно вернуть шаблонный литерал.

В ES5:

var classes = 'header'
classes += (isLargeScreen() ?
   '' : item.isCollapsed ?
     ' icon-expander' : ' icon-collapser');

В ES2015 с шаблонными литералами без вложения:

const classes = `header ${ isLargeScreen() ? '' :
    (item.isCollapsed ? 'icon-expander' : 'icon-collapser') }`;

В ES2015 с вложенными шаблонными литералами:

const classes = `header ${ isLargeScreen() ? '' :
`icon-${item.isCollapsed ? 'expander' : 'collapser'}` }`;

[Смотритель]

Роман, да я не против - с моим вопросом помог разобраться Алексей, это главное.
Просто по вашему вопросу вряд ли кто зайдет в мой топик и подскажет чего =)

[Роман]

Артем, да и подсказывать то более нечего, ведь в отличиях стрелочных и обычных функций вы уже прекрасно разобрались)

разве что вот еще есть возможность использовать call, apply и bind когда надо передать или жестко привязать контекст.

Answer 3

[Robur]

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

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

Если по сути примера - self у вас будет в замыкании, останется там висеть пока где-то есть живая ссылка на это замыкание, то есть пока где-то есть ссылка на функцию которую вы передаете в helper.method. как только сборщик мусора сможет это все собрать - память освободится. Если ссылки не умирают и вы вызываете эту функцию раз за разом - память закончится даже если вы уберете self вообще.

Тут важно убедиться что у вас нигде нет утечек памяти. Если код такой что должен работать долго, упорно и хорошо, например большие и сложные математические вычисления или важен реалтайм (чтобы сборщик мусора не ставил все внезапно на паузу) - то тут нужны специальные техники, чтобы по максимуму избежать создания любого нового объекта в памяти.

Читайте про сборщик мусора, как он работает и откуда берутся утечки памяти в node.

Comments

[Смотритель]

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

вместо:

function req(params, ext) {
	helper.method(params, (body) => {
		this.result(body, ext);
	});
};

использовать:

function req(params, ext) {
	helper.method(params, this.result);
};

Но встает вопрос в пааметре "ext" - как его транслировать в this.result - кроме как создавать эту "анонимную обертку". Может подсказать сможете, если такое вообще возможно?

[Robur]

Артем, нужно менять helper.method. Или же передавать ext где-то еще, может у вас есть какой-то общий объект стейта куда его можно положить.
Если вариантов ext не сильно много и конечное количество, то можно сделать memoization для result - будет столько копий сколько вариантов ext.

[Смотритель]

Robur, боюсь, что нет... в данном случае это так для примера упрощенный вид, а вообще там параметризация частично из входных данных, частично из расчетных в методе req(){...} - вот и выходит, что без создания анонимки одна фигня не обойтись, как бы мне этого не хотелось. Сам понимаю, что на каждый вызов создавать новую "обертку" и потом ждать, когда там мусорщик доберется до всего, что с ней связано и вычистит, это не самый лучший вариант - но как иначе?
Даже если делать некую общую область памяти и в нее пихать такие "пробрасываемые" данные, все равно ведь надо их как-то идентифицировать, чтобы потом обработчик функции обратного вызова понимал, какой блок данных надо запросить из этого "общего банка"... К тому же потребуется химичить и своего "мусорщика", который будет чистить этот "банк" от лишних данных по некоему алгоритму (аля таймаут или еще чего)...

[Robur]

Я вам написал самый простой вариант - менять helper.method. Чтобы он принимал все данные целиком, и с ними вызывал ваш колбек.
Насчет своего мусорщика - если вам нужна будет сложную работу с данными чтобы сделать код максимально оптимизированным - то у вас будет сложная работа с данными. Другой вопрос - нужно ли вам это на самом деле.
Вообще переиспользовать объекты можно по разному - если у них шейп одинаковый, например, сделать пул, оттуда их брать и туда же отдавать. так вы можете их гонять по приложению без пересоздания. Методов много, но если вы хотите пару строчек магических написать и все будет здорово - не получится, было бы просто - все бы так делали.

[Смотритель]

Robur, ок, хорошо, может быть пример с объектом "helper" не очень получился наглядным... Давайте примем вариант, что helper - это объект работы с REDIS например, или с MONGO - не суть с чем, это просто объект какого-то модуля из NPM. Они на вход принимают конкретные параметры, и выдают результат с конкретными данными (аргументами функций обратного вызова).
Ну вот как можно тут решить задачу, если нужно в обработчик передать не только результат вызова метода объекта модуля, но и какие-то доп. данные?
ЗЫ. я не ищу легких путей, он существует только один и всем известный "махнуть рукой и послать все на йух", но это не наш путь =)

[Robur]

Артем, например - форкнуть и поменять как надо. Или взять нативный драйвер и написать вокруг него свою спец объвязку, с минимальным оверхедом и memory footprint, если это для вас настолько важно.
Если не настолько важно - то о чем сыр-бор? расслабьтесь :)
У меня складывается впечатление что вы хотите не потому что есть реальная потребность а "из принципа". Заморочиться чтобы заморочиться - тут вам никто не помешает развлекаться так как заблагорассудится.

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

[Смотритель]

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

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

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

[Robur]

Артем, Тут уж вы сами выбираете нужный уровень "жести" исходя из задачи и количества ресурсов которые можно на это потратить. Написать свою обвязку к mongo драйверу чтобы она работала быстрее/была меньше это довольно лайтовый вариант, ничего сложного.