Сообщение Re: ref-сборки в dotnet core от 15.01.2022 21:43
Изменено 15.01.2022 22:42 Mystic Artifact
Re: ref-сборки в dotnet core
Здравствуйте, vaa, Вы писали:
Всё для чего служат реф-асм это удовлетворение МС-ного воркфлоу с in-place апдейтами для 4.x фреймворками (оттуда оно и выросло), сохраняя обратную совместимость (возможность таргетироваться назад). Более ни для чего оно не нужно, более того, то что они сделали и как оно работает (розлин) — то это не оптимизация, это признание собственной импотенции, под видом стратегической оптмизации и только это. Ничего хорошего в этой ахинеи нет.
Чисто теоретически, ref-сборка помогает, когда вы потребляете пакеты. Но воистинну, на типичных размерах пакетах — это абсолютно не важно, и скорее вызывает деградацию (т.к. вам нужно читать в 2 раза больше файлов, чем стоит). Вот и всё. [Тут ещё вам расскажут про блокировку файлов, но компилятору не надо держать ссылки — ему нужно делать ровно то, что его просят, а не то, что делает вся эта малоуправляемая махина, порождая неконтроллируемое кол-во процессов которые висят которых вы — непросили.]
При этом, я вынужден добавить, что вместо того, что бы купить нюгет или как они там договорились ещё тогда давно и выкинуть .ps1 и прочее говно — они пошли по пути только придумывания костылей над костылями. Теперь вот всё продолжают и продолжают выдумать новые костыли. Вместе с тем, для решения *практических* задач — оно не годиться. Точнее говоря, они не гарантируют этого. В частности: мета-пакетов — нет. Точнее не так, они есть и работают и в дотнете и у меня. Но, они официально не поддерживаются. Библиотеку установить на системном уровне (на подобии asp.net) — ну это тоже несколько для избранных. Зарезолвить путь к такому пакету в райнтайме — собственно охереете. Я уже не говорю, что нюгет пакеты не умеет восстанавливать, так, как оно должно было быть изначально, и что указание версии 1.2.3 это не совсем то же что и [1.2.3] как видится большинством людей.
В некоторых вопросах, — они просто нагло врут сказки, как они сделали в прошлом году про PGO, которое они действительно прикрутили, но только для своих библиотек, не дав нормального доступа до тулчейна, при этом не забыли жирно похватиться.
Всё для чего служат реф-асм это удовлетворение МС-ного воркфлоу с in-place апдейтами для 4.x фреймворками (оттуда оно и выросло), сохраняя обратную совместимость (возможность таргетироваться назад). Более ни для чего оно не нужно, более того, то что они сделали и как оно работает (розлин) — то это не оптимизация, это признание собственной импотенции, под видом стратегической оптмизации и только это. Ничего хорошего в этой ахинеи нет.
Чисто теоретически, ref-сборка помогает, когда вы потребляете пакеты. Но воистинну, на типичных размерах пакетах — это абсолютно не важно, и скорее вызывает деградацию (т.к. вам нужно читать в 2 раза больше файлов, чем стоит). Вот и всё. [Тут ещё вам расскажут про блокировку файлов, но компилятору не надо держать ссылки — ему нужно делать ровно то, что его просят, а не то, что делает вся эта малоуправляемая махина, порождая неконтроллируемое кол-во процессов которые висят которых вы — непросили.]
При этом, я вынужден добавить, что вместо того, что бы купить нюгет или как они там договорились ещё тогда давно и выкинуть .ps1 и прочее говно — они пошли по пути только придумывания костылей над костылями. Теперь вот всё продолжают и продолжают выдумать новые костыли. Вместе с тем, для решения *практических* задач — оно не годиться. Точнее говоря, они не гарантируют этого. В частности: мета-пакетов — нет. Точнее не так, они есть и работают и в дотнете и у меня. Но, они официально не поддерживаются. Библиотеку установить на системном уровне (на подобии asp.net) — ну это тоже несколько для избранных. Зарезолвить путь к такому пакету в райнтайме — собственно охереете. Я уже не говорю, что нюгет пакеты не умеет восстанавливать, так, как оно должно было быть изначально, и что указание версии 1.2.3 это не совсем то же что и [1.2.3] как видится большинством людей.
В некоторых вопросах, — они просто нагло врут сказки, как они сделали в прошлом году про PGO, которое они действительно прикрутили, но только для своих библиотек, не дав нормального доступа до тулчейна, при этом не забыли жирно похватиться.
Re: ref-сборки в dotnet core
Здравствуйте, vaa, Вы писали:
Всё для чего служат реф-асм это удовлетворение МС-ного воркфлоу с in-place апдейтами для 4.x фреймворками (оттуда оно и выросло), сохраняя обратную совместимость (возможность таргетироваться назад). Более ни для чего оно не нужно, более того, то что они сделали и как оно работает (розлин) — то это не оптимизация, это признание собственной импотенции, под видом стратегической оптмизации и только это. Ничего хорошего в этой ахинеи нет.
Чисто теоретически, ref-сборка помогает, когда вы потребляете пакеты. Но воистинну, на типичных размерах пакетах — это абсолютно не важно, и скорее вызывает деградацию (т.к. вам нужно читать в 2 раза больше файлов, чем стоит). Вот и всё. [Тут ещё вам расскажут про блокировку файлов, но компилятору не надо держать ссылки — ему нужно делать ровно то, что его просят, а не то, что делает вся эта малоуправляемая махина, порождая неконтроллируемое кол-во процессов которые висят которых вы — непросили.]
При этом, я вынужден добавить, что вместо того, что бы купить нюгет или как они там договорились ещё тогда давно и выкинуть .ps1 и прочее говно — они пошли по пути только придумывания костылей над костылями. Теперь вот всё продолжают и продолжают выдумать новые костыли. Вместе с тем, для решения *практических* задач — оно не годиться. Точнее говоря, они не гарантируют этого. В частности: мета-пакетов — нет. Точнее не так, они есть и работают и в дотнете и у меня. Но, они официально не поддерживаются. Библиотеку установить на системном уровне (на подобии asp.net) — ну это тоже несколько для избранных. Зарезолвить путь к такому пакету в райнтайме — собственно охереете. Я уже не говорю, что нюгет пакеты не умеет восстанавливать, так, как оно должно было быть изначально, и что указание версии 1.2.3 это не совсем то же что и [1.2.3] как видится большинством людей. ADD: (Самый трэш с транзитивными зависимостями, но суть то не в том: есть старое решение на уровне мсбилда и уже пилят новую фичу про центральное управление и она уже дебильна, т.к. идет путем спец поддержки. Как так? Ведь работающий исходник не основывается на несуществующих фичах, да и фича — то по сути не может быть фича: это уже базовый функционал...) Есть еще много проблем в этом русле, типа транзитивный флоу проектов или пакетов, и надо руками писать когда ты этого не хочешь. И если думают, что реф-файлы помогут в скорости... тьфу на них трижды, т.к. проблема в том, что это как раз не важно: будете бороться с проектами внутри солюшна. Конечно мсбилд тьюринг полный и это же его слабость: билд процесс охеренно неронятный. В сравнении с C++ где непонятности обычно больше в купе с сторонними тупыми тулзами-генераторами (cmake) тди сторонними внятными языками-генераторами (gn) — msbuild проще в типичном использовании и в целом интересен, но проблема doible-writes вот специфична для него (не только для него на самом деле), но они так и подталкивают что бы сделать всё вместо них. При этом это непрактично.
В некоторых вопросах, — они просто нагло врут сказки, как они сделали в прошлом году про PGO, которое они действительно прикрутили, но только для своих библиотек, не дав нормального доступа до тулчейна, при этом не забыли жирно похватиться.
Всё для чего служат реф-асм это удовлетворение МС-ного воркфлоу с in-place апдейтами для 4.x фреймворками (оттуда оно и выросло), сохраняя обратную совместимость (возможность таргетироваться назад). Более ни для чего оно не нужно, более того, то что они сделали и как оно работает (розлин) — то это не оптимизация, это признание собственной импотенции, под видом стратегической оптмизации и только это. Ничего хорошего в этой ахинеи нет.
Чисто теоретически, ref-сборка помогает, когда вы потребляете пакеты. Но воистинну, на типичных размерах пакетах — это абсолютно не важно, и скорее вызывает деградацию (т.к. вам нужно читать в 2 раза больше файлов, чем стоит). Вот и всё. [Тут ещё вам расскажут про блокировку файлов, но компилятору не надо держать ссылки — ему нужно делать ровно то, что его просят, а не то, что делает вся эта малоуправляемая махина, порождая неконтроллируемое кол-во процессов которые висят которых вы — непросили.]
При этом, я вынужден добавить, что вместо того, что бы купить нюгет или как они там договорились ещё тогда давно и выкинуть .ps1 и прочее говно — они пошли по пути только придумывания костылей над костылями. Теперь вот всё продолжают и продолжают выдумать новые костыли. Вместе с тем, для решения *практических* задач — оно не годиться. Точнее говоря, они не гарантируют этого. В частности: мета-пакетов — нет. Точнее не так, они есть и работают и в дотнете и у меня. Но, они официально не поддерживаются. Библиотеку установить на системном уровне (на подобии asp.net) — ну это тоже несколько для избранных. Зарезолвить путь к такому пакету в райнтайме — собственно охереете. Я уже не говорю, что нюгет пакеты не умеет восстанавливать, так, как оно должно было быть изначально, и что указание версии 1.2.3 это не совсем то же что и [1.2.3] как видится большинством людей. ADD: (Самый трэш с транзитивными зависимостями, но суть то не в том: есть старое решение на уровне мсбилда и уже пилят новую фичу про центральное управление и она уже дебильна, т.к. идет путем спец поддержки. Как так? Ведь работающий исходник не основывается на несуществующих фичах, да и фича — то по сути не может быть фича: это уже базовый функционал...) Есть еще много проблем в этом русле, типа транзитивный флоу проектов или пакетов, и надо руками писать когда ты этого не хочешь. И если думают, что реф-файлы помогут в скорости... тьфу на них трижды, т.к. проблема в том, что это как раз не важно: будете бороться с проектами внутри солюшна. Конечно мсбилд тьюринг полный и это же его слабость: билд процесс охеренно неронятный. В сравнении с C++ где непонятности обычно больше в купе с сторонними тупыми тулзами-генераторами (cmake) тди сторонними внятными языками-генераторами (gn) — msbuild проще в типичном использовании и в целом интересен, но проблема doible-writes вот специфична для него (не только для него на самом деле), но они так и подталкивают что бы сделать всё вместо них. При этом это непрактично.
В некоторых вопросах, — они просто нагло врут сказки, как они сделали в прошлом году про PGO, которое они действительно прикрутили, но только для своих библиотек, не дав нормального доступа до тулчейна, при этом не забыли жирно похватиться.