Definitelytyped: [@ types / styled-components] Проблемы с производительностью компилятора

Созданный на 2 апр. 2019  ·  37Комментарии  ·  Источник: DefinitelyTyped/DefinitelyTyped

Добавление последней версии @ types / styled-components в существующий проект приводит к увеличению времени сборки примерно на 1-2 минуты при использовании последней версии [email protected].

Используя это исходное репо , я протестировал следующие версии:

w/o     2.3s
4.0.0   5.6s
4.1.0   8.0s
4.1.5   8.0s
4.1.10  10.1s
4.1.11  90.1s
4.1.12  97.1s

Моя машина - это ноутбук с Linux 4.18.0 (Ubuntu 18.10) с процессором i7-6700HQ @ 2,60 ГГц.

Кажется очевидным, что выпуск 4.1.11 является причиной этой проблемы с производительностью. PR для этого выпуска - # 33061. Что касается того, почему, я действительно не знаю - я пытался покопаться во внутренностях компилятора, чтобы увидеть, где он застрял, но я не мог этого понять.

  • [x] Я пробовал использовать пакет @types/xxxx , и у меня возникли проблемы.
  • [x] Я пробовал использовать последнюю стабильную версию tsc. https://www.npmjs.com/package/typescript
  • [x] У меня вопрос, который не подходит для StackOverflow . (Пожалуйста, задавайте там любые уместные вопросы).
  • [x] [Упоминание] (https://github.com/blog/821-mention-somebody-they-re-notified) авторов (см. Definitions by: в index.d.ts ), чтобы они могли отвечать.

    • Авторы: @ eps1lon @Igorbek @Jessidhia

Самый полезный комментарий

@RyanCavanaugh снова откроется?

Все 37 Комментарий

Это тоже происходит с машинописным текстом 3.3?

У меня такая же проблема

package.json

devDependency

"@babel/core": "^7.4.0",
"@babel/plugin-proposal-class-properties": "^7.4.0",
"@babel/plugin-syntax-dynamic-import": "^7.2.0",
"@babel/plugin-transform-async-to-generator": "^7.4.0",
"@babel/preset-env": "^7.4.2",
"@babel/preset-react": "^7.0.0",
"@babel/preset-typescript": "^7.3.3",
"babel-jest": "^24.5.0",
"babel-loader": "^8.0.5",
"babel-plugin-styled-components": "^1.10.0",
"css-loader": "^2.1.1",
"file-loader": "^3.0.1",
"html-webpack-plugin": "^3.2.0",
"jest": "^24.5.0",
"mini-css-extract-plugin": "^0.5.0",
"node-sass": "^4.11.0",
"react-svg-loader": "^2.1.0",
"regenerator-runtime": "^0.13.2",
"sass-loader": "^7.1.0",
"style-loader": "^0.23.1",
"ts-loader": "^5.3.3",
"typescript-tslint-plugin": "^0.3.1",
"webpack": "^4.29.6",
"webpack-cli": "^3.3.0",
"webpack-dev-server": "^3.2.1"

зависимость

"@babel/polyfill": "^7.4.0",
"@loadable/component": "^5.7.0",
"@types/loadable__component": "^5.6.0",
"@types/react": "^16.8.10",
"@types/react-dom": "^16.8.3",
"@types/react-router-dom": "^4.3.1",
"@types/styled-components": "4.1.5",
"axios": "^0.18.0",
"react": "^16.8.6",
"react-dom": "^16.8.6",
"react-router": "^5.0.0",
"react-router-dom": "^5.0.0",
"styled-components": "^4.2.0",
"styled-normalize": "^8.0.6",
"typescript": "^3.4.1"

Моя проблема в том, что похоже, что webpack и webpack-dev-server не могут анализировать @ types / styled-components. Потому что при использовании только стилизованных компонентов проблем не было. Это всегда происходит при одновременном использовании @ types / [email protected] .

Прежде чем увидеть проблему @voliva , я обнаружил проблему с бесконечным циклом веб-пакета, потому что он на 100% использует ресурс процессора.

После изменения версии @ types / styled-compoents на 4.1.5 вроде все в порядке.

@ eps1lon : Нет, машинопись 3.3 3.4.0-dev.20190226 .

Используя репозиторий семян OmitU , добавленного в @ types / styled-components версии 4.1.1. Вот его определение :

type OmitU<T, K extends keyof T> = T extends any ? PickU<T, Exclude<keyof T, K>> : never;

И вот оба места, где OmitU используется в index.d.ts :

Определение WithOptionalTheme

type WithOptionalTheme<P extends { theme?: T }, T> = OmitU<P, "theme"> & {
    theme?: T;
};

Использование WithOptionalTheme (в определении StyledComponentProps )

WithOptionalTheme<
    OmitU<
        ReactDefaultizedProps<
            C,
            React.ComponentPropsWithRef<C>
        > & O,
        A
    > & Partial<PickU<React.ComponentPropsWithRef<C> & O, A>>,
    T
>

Что-то в распределенном объединением OmitU сопоставлении с другим OmitU кажется, сбивает компилятор. Если один или оба этих экземпляра заменены обычным Omit , который не распространяется по объединениям, время компиляции сокращается до разумных 10 секунд или около того в соответствии с машинописным текстом 3.4.1.

(Обратите внимание, что тип ReactDefaultizedProps также ссылается на PickU , что может помочь объяснить особенно длительное время работы во второй строке таблицы ниже.)

Чтобы проверить это, я заменил один или оба распределенных OmitU s одним из следующих:

type OmitPickU<T, K extends keyof T> = PickU<T, Exclude<keyof T, K>>;
type Omit<T, K extends keyof T> = Pick<T, Exclude<keyof T, K>>;

Вот time yarn tsc run против машинописного текста 3.4.1 , 3.4.0-dev.2019 0226 и непосредственного предыдущего выпуска 3.4.0-dev.2019 0223 :

| WithOptionalTheme определение | WithOptionalTheme использование | машинопись 3.4.1 | машинописный текст 3.4.0-dev.20190226 | машинописный текст 3.4.0-dev.20190223 |
| --- | --- | --- | --- | --- |
| OmitU | OmitU | 1m28.984s | 0m55.853s | 0m6.031s |
| OmitU | OmitPickU | 2m49.492s | 1 мин. 49,457 сек. | 0m5.961s |
| OmitPickU | OmitU | 1m10.313s | 0m35.278s | 0m6.125s |
| OmitPickU | OmitPickU | 0m10.501s | 0m6.947s | 0m6.055s |
| OmitU | Omit | 0m9.611s | 0m6.781s | 0m6.102s |
| Omit | OmitU | 0m10.471s | 0m7.451s | ... и т. д. |
| OmitPickU | Omit | 0m9.654s | 0m6.796s | |
| Omit | OmitPickU | 0m8.990s | 0m6.485s | |
| Omit | Omit | 0m9.730s | 0m6.815s | |

Время выполнения машинописного текста 3.3.3 и 3.3.4000 соответствует 3.4.0-dev.20190223 - примерно 6 секунд по всем направлениям.

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

Я могу подтвердить, что у меня такая же проблема. У меня тоже сработало понижение версии @ types / styled-components до 4.1.5. Я на машинописи 3.4.1

@michsa Я ожидал некоторого снижения, но не в 10 раз. Поскольку это было введено в машинописном тексте 3.4, не могли бы вы открыть проблему и в репозитории машинописных текстов? Я хотел бы убедиться, что мы не откатим исправление ошибки, если это регресс, который следует исправить в машинописном тексте.

Извините, я изначально не искал в github typescript, я обнаружил эту проблему, которую они в настоящее время исследуют: https://github.com/Microsoft/TypeScript/issues/30663

@weswigham @RyanCavanaugh Можем ли мы быстро опубликовать возврат к типам стилизованных компонентов, у которых нет проблем с производительностью в 3.4.

С выпуском VS Code 1.33 многие пользователи js будут загружать ошибочные типы через автоматическое получение типов. Как только это произойдет, чтобы выйти из плохого состояния, я считаю, что вам нужно либо очистить кеш автоматического получения типа, либо установить фиксированный @types/styled-components . Также плохие впечатления для пользователей js. Чем дольше будет последняя опубликованная версия неэффективного набора текста, тем больше пользователей будут затронуты (что для них является плохим опытом и требует много дополнительной работы для нас).

Похоже, это все еще может быть проблемой с @ types / styled-components 4.1.19 и TS 3.6.3. Завершение TS и выделение ошибок занимает 5-10 + секунд на i7 macbook pro 15 2018 г. Необходимо провести дополнительное расследование.

Эмм, OP говорит о компиляциях 90-х годов (скачок в 9 раз по сравнению с предыдущей версией стилизованных компонентов), поскольку обе более поздние версии TS имеют смягчения, а более поздние версии стилизованных компонентов были упрощены, чтобы не иметь так много перфоманса. проблем, 5-10 секунд - это, возможно, просто ваш проект, и депеши ведут себя нормально.

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

Мой VSCde непригоден для использования (ошибки ts появляются и исчезают через несколько секунд, а не мгновенно), как только я добавляю @ types / styled-components.

Я использую TS 3.6.4 и типы 4.1.20.

@sregg обвиняет этот PR, который отменил смягчение в @types/styled-components : https://github.com/DefinitiTyped/DefinentyTyped/pull/39323

(И вернитесь к v 4.1.19 чтобы исправить проблему локально)

@sregg обвиняет этот PR, который отменил смягчение в @types/styled-components : # 39323

@ typescript-bot собирает показатели производительности, чтобы «оценить, может ли [PR] отрицательно повлиять на время компиляции или скорость реакции редактора». В PR 39323 @ typescript-bot заключил: «Похоже, ничего не изменилось слишком сильно». .

@sregg , можете ли вы придумать причину, по которой существующие метрики @ typescript-bot не могут выделить наблюдаемую вами проблему с производительностью редактора?

(Боковая панель: «обвиняй этот пиар» - неконструктивное предложение, @weswigham. Пожалуйста, будьте конструктивны.)

Вот дополнительный контекст:

@sregg сообщил о низкой производительности при использовании TypeScript 3.6.4: https://github.com/DefinitiTyped/DefinitiTyped/issues/34391#issuecomment -548701239

Но из ответа @weswigham в https://github.com/microsoft/TypeScript/issues/30663#issuecomment -507406245 я понял, что версии TypeScript ≥3.5 больше не будут нести штраф за производительность, который https://github.com/DefinitiTyped / ОпределенноTyped / pull / 34499 был объединен, чтобы избежать.

Итак, с этим пониманием, я решил (более или менее) вернуть https://github.com/DefinentyTyped/DefinitiTyped/pull/34499 через https://github.com/DefinitiTyped/DefinentyTyped/pull/39323.

Показатели производительности бота основаны на том, что находится в тестах, и, к сожалению, тесты стилизованных компонентов довольно далеки от реального приложения как по размеру, так и по (сложному) использованию. Он делает все, что в его силах, с тем, что у него есть, однако он не всегда обнаруживает проблемы с _every_ perf.

(Боковая панель: "виноват" в смысле "мерзавец" - пожалуйста, не обижайтесь ~)

В этом есть смысл, спасибо @weswigham!

Пока мы не сможем зафиксировать снижение производительности в тестах, я думаю, что лучший способ действий - вернуть PR https://github.com/DefinitiTyped/DefinentyTyped/pull/39323 , поэтому я открыл PR https://github.com. / ОпределенноТипед / ОпределенноТипед / pull / 40095, чтобы сделать это.

На следующей неделе я буду работать над добавлением теста на основе отчетов (например, https://github.com/DefinitiTyped/DefinitiTyped/pull/39323#issuecomment-549015652), которые были опубликованы. Как только это сработает, мы можем (заранее) оценить другие решения, подобные https://github.com/DefinentyTyped/DefinentyTyped/pull/39323.

@smockle вы пробовали запустить последнюю версию (4.4.2)? Похоже, ошибка производительности снова вернулась, помогает переход на 4.1.19.


UPD: То же самое с типами sc v5.0.1

@sregg
Я тоже!!!

Мой VSCode (* на самом деле TS-SERVER) работает медленнее, чем раньше. после использования styled-components.
"@types/styled-components": "^5.1.0", "styled-components": "^5.1.1" "typescript": "^3.9.5"

После понижения TS с 3.9.X до 3.8.3 производительность снова вернулась к норме. Использование "@types/styled-components": "^5.1.0" и "styled-components": "^5.1.1" .

Спасибо @joaopaulobdac , я работал над одним проектом, который значительно медленнее при оценке машинописного

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

У меня такая же проблема с последней версией от июня 2020 г. (версия 1.47) и "@ types / styled-components": "^ 5.1.1"

Использование машинописного текста 3.9.3 с версией стилизованных компонентов 5.1.1 полностью снижает производительность моего сервера VSCode TS. Это абсолютно непригодно: D Переход на машинную версию 3.8.3 похоже, восстанавливает по крайней мере часть производительности, но это действительно требует некоторого внимания.

@RyanCavanaugh снова откроется?

Могу подтвердить, испытываете ту же проблему.

То же самое, стоит открыть заново!

Я подтверждаю, что мой VSCode начал подавляться.

Я закончил тем, что удалил стилизованные компоненты, в любом случае это не принесло нам особой пользы от react-native. Простые старые объекты JS с оператором распространения и встроенными стилями отлично работают без проблем с перфомансом TS, в конечном итоге IMO легче читать код, чем со стилизованными компонентами, по крайней мере, на RN.

Когда я кодирую с помощью VSCode, я испытываю ад в убежище CSS-in-JS.

@AndrewMorsillo @hilezir Я переключился со стилизованных компонентов на стилетрон, используя TS 4. Производительность в стилетроне намного лучше как в vscode, так и в браузере. Но я ничего не знаю о стилетроне на React Native.

@AndrewMorsillo @hilezir Я переключился со стилизованных компонентов на стилетрон, используя TS 4. Производительность в стилетроне намного лучше как в vscode, так и в браузере. Но я ничего не знаю о стилетроне на React Native.

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

Будет ли новый выпуск или этот выпуск будет открыт повторно? По-прежнему существуют большие проблемы с производительностью с @ types / styled-components 5.1.2 и TS 3.9.7.

Потратил целый день, пытаясь выяснить, как ускорить VSCode, и _ наконец_ понял, что это @types/styled-components . Когда он установлен, простой ввод чего-либо в редакторе вызовет скачок tsserver.js (как показано через VSCode Process Explorer)> 100% ЦП и неограниченный рост памяти. Простое удаление @types/styled-components исправило это.

Я использовал TypeScript 4.0.3 и @types/styled-components 5.1.3.

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

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

попробуй это?

  1. https://material-ui.com/styles/basics/#material -ui-styles

  2. https://emotion.sh/docs/styled#styling -elements-and-components

На самом деле существует открытый запрос на вытягивание для повышения производительности типов styled-components : https://github.com/DefinitiTyped/DefinentyTyped/pull/46510.

Была ли эта страница полезной?
0 / 5 - 0 рейтинги