Demian Smith

значит узкое место почти наверняка диск.

Пальцем в небо, файловая система на которой таблеспейсы лежат какая? случайно не cow (btrfs/zfs/xfs)? с ними отвратительно работают базы данных, так как частые записи в файл генерируют сильную фрагментацию. В этом случае перед тяжелой обработкой хотя бы дефрагментируй файлы базы и отключи cow фичу на таблеспейсах

неплохим тюнингом может оказаться (на выбор):
* разместить базу в ram диске (буквально, залить на сервер в облаке, обработать данные, залить назад, работая напрямую с таблеспейсами, но версия софта должна совпадать до последней цифры)
* разместить базу целиком на ssd (даже если это будет потребительский и дешевый)
* добавить в систему ssd кеш для hdd с помощью например bcache (включенный на запись), правда для линейной обработки базы это может дать мало пользы, но вообще это неплохой способ на порядок поднять производительность за дешево (в одном месте я использовал фичу virtualbox со снапшотами в файл, есть и у kvm, когда последующие записи шли не на исходный образ а на другой диск, и он ssd)
* разместить таблеспейс для индексов (а может и каждую таблицу отдельно) на другом физическом устройстве (hdd, ssd или даже в ram), требования к размеру тут обычно низкие, ключевое слово - исключить последовательные чтения/записи на одно устройство.
* разместить журнал (например ext4) на ssd диск (хватит пары гигабайт) или по хардкору даже отключить его (очень опасно, можно получить кашу из данных при сбое питания, но как временное решение пока идет долгая операция, при наличии всех бакапов, оправдано) - наименьшая оптимизация, но при частых мелких записях это заметно

Как бы это странно не звучало, но одно из главных преимуществ TypeScript - это ускорение разработки в несколько раз. Да, когда еще ничего нет - разработка незначительно замедлится, так как помимо логики нужно описать еще и типы. Но это только в начале. И это не только возможность писать большую часть кода с помощью автодополнения. Поддержка существующего кода занимает в десятки раз больше времени, чем его начальное написание. Стоит ли вложить несколько лишних часов на старте, чтоб сэкономить в последствии месяцы? Как по мне стоит.

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

Ну и отвчечу на некоторые Ваши сомнения:

TSLint в VSCode прям жутко тугой

TSLint официально deprecated, вместо него стоит использовать плагин к eslint, заодно можете мой конфиг попробовать.

Типы? Есть JSDOC

JSDoc в плане типов не умеет и 10% того, что умеет TypeScript. Кроме того, никто в здравом уме не пишет JSDoc на приватную логику, а значит проверки типов там не будет. JSDoc не гарантирует корректность рефакторинга, а вот благодаря TypeScript я, опять таки, точно не забуду обновить JSDoc.

многие библиотеки nodejs не имеют типов

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

Поддержка браузерами скомпилированного кода? Да какбы почти весь JS имеет поддержку 95%+, тот же Babel уже забыл когда использовал.

Вообще это не основная задача компилятора TypeScript, а опциональная возможность. И babel + preset-env с ней справляются гораздо лучше. И никто не мешает использовать их вместе. А еще думаю вопрос времени, когда кто-то напишет оптимизатор кода использующий информацию о типах из TS.

Примерно в каждой второй есть инстансы, на которые смотришь - и чешешь репу - а как называется тип этой переменной в @types/?

import {someObject} from 'some-library';

type TypeFromValue = typeof someObject;
const valueCopy: TypeFromValue = {
    ...someObject,
    type: 'overrides',
    with: 'type check',
};

и кстати, вот пример того что JSDoc типы не умеют.

//@ts-check

и почти везде останется бесполезный any.

P.S. удачи такие типы на JSDoc описывать
P.P.S. Еще прелести современного TypeScript невозможные у...

Используйте классы для управления состоянием. И классы меняйте кодом.

.menu {
  opacity: 0; /* по умолчанию скрыто */
}
.menu-opened {
  opacity: 1; /* при добавлении класса - открыто */
}

@media (min-width: 992px) {
  .menu {
    opacity: 1; /* на больших экранах – всегда открыто */
  }
}

//...
burger.classList.toggle('open');
burger.classList == 'open'
  ? menu.classList.add('menu-opened')
  : menu.classList.remove('menu-opened');

Кстати, что это такое: burger.classList == 'open'?
Проверку так делают:
burger.classList.contains('open');

В ошибке сказано , что вы должно использовать useState только в функции

import React, { useState } from "react";

const MemoID = ({ getID }) => {
  return Array.from(new Array(getID)).map((_, i) => {
    return <p key={i}> {i} </p>;
  });
};

export default function App() {
  let [getID, setID] = useState(0);
  return (
    <>
      <MemoID key={getID} {...{ getID }} />
      <button onClick={() => setID(getID + 1)}> clickMe </button>
    </>
  );
}

https://codesandbox.io/s/jolly-fermi-lioe7?file=/s...

f(x) = O(g(x)) при x→y — это так называемый символ Ландау.
И означает, что при x, достаточно близких к y, f(x)<k·g(x). Так что 2x или 1000x — извините, не важно.

Отсюда же запись O(log n) — ведь разные логарифмы отличаются на константу, которую символы Ландау съедают.

Чем символы Ландау интересны программистам?
1. Кэшами, быстрым процессором, «хитрым» программированием и прочим на больших наборах данных можно выиграть, например, в разы. Порядком сложности алгоритма — намного, намного больше.
2. Пока закон Мура действовал, объёмы данных росли экспоненциально — так что быстро доходило до того, что программу начинали использовать на наборах данных, для которых она просто не предназначалась.
3. Практически приемлемые алгоритмы обычно имеют небольшую сложность — например, до O(n³). И, например, линейный алгоритм за приемлемое время обработает миллионы элементов, n log n — сотни тысяч, n² — тысячи, n³ — сотни.
4. Программисты отлаживают на небольших наборах данных, которые можно обработать вручную. Так что разница между отладочными и боевыми данными бывает большая — а значит, порядок сложности должен влиять сильнее, чем остальные факторы.

Оформляете так

function calc(a,b,c){
    return (a * b + c) / 20
}
export default calc;

подключаете так
import calc from '../code/calc'

Мне нравится как описано в этой статье https://ncjamieson.com/avoiding-takeuntil-leaks/

Подробнее про подписки https://medium.com/ngx/why-do-you-need-unsubscribe...

Насколько я знаю, _ в JS является валидным именем переменной, такую переменную можно создать, обращаться к ней и т.д. Так получается что я просто передаю в ф-цию неиспользуемую переменную?? Тоже самое как сделал бы a => { ... } ??

Именно так.

Лично я отдаю предпочтение () => { ... } по ряду причин:

1. Нет неиспользуемых переменных. Нет ругательств со стороны линтеров. Для рантайма это мизерное, но всё таки, улучшение производительности
   
2. Если говорить про TS, то тут вообще не рекомендуется синтаксис a => { ... }, только (a) => { ... }. И банально проще, когда у тебя весь код по разным проектам в одном стиле.
   
3. Мне так больше нравится чисто эстетически.
   

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

interface PostAttachVideo {
  type: 'video'
  attach: AttachVideo
}

interface PostAttachAudio {
  type: 'audio'
  attach: AttachAudio
}

type PostAttach = PostAttachAudio | PostAttachVideo

function isAudio(attach: PostAttach): attach is PostAttachAudio {
    return attach.type === 'audio';
}

песочница