Itu aneh. Apa versi Node Anda?

@PatSmuk360 Bisakah Anda menguji dan mendapatkan profil memori 3.10.0 dan melihat apakah itu berbeda?

Kami menjalankan versi terbaru 10 (10.16.3).

Cuplikan tumpukan sebelumnya:

Cuplikan tumpukan setelah:

Saya juga mencoba Node 12.10.0 dan tampaknya jauh lebih buruk, mencapai penggunaan memori 587 MB pada satu titik dalam build berurutan.

Profil CPU sebelumnya:
CPU-20190916T133934.cpuprofile.zip

Profil CPU setelah:
CPU-20190916T134917.cpuprofile.zip

@PatSmuk360 Jadi, panjang dan pendeknya perbedaan antara versi tersebut adalah basis kodenya diubah menjadi sintaks ES6. Yang secara teknis bukan perubahan besar, itulah sebabnya itu bukan versi utama.

TAPI... kecurigaan saya adalah bahwa beberapa konversi Babel untuk hal-hal seperti sintaks penyebaran objek/array kurang efisien daripada versi ES5 yang lebih verbose. Itu sebabnya saya bertanya apakah Anda bisa menguji 3.10.0, karena awalnya saya mengekspor paket transpiled yang kompatibel dengan Node 6 dan lebih tinggi, tetapi itu merusak integrasi dengan perpustakaan tertentu yang tidak dapat menangani sintaks kelas. Jadi saya pergi ke Node 4 tanpa konstruksi kelas.

Jika kita dapat mengetahui dengan tepat transformasi ES5 mana yang tidak berperforma baik, secara teoritis kita dapat mengatur pengaturan ekspor Babel secara lebih terperinci ke ekspor yang lebih berkinerja.

@PatSmuk360 Kebetulan, apa fungsi split yang menghabiskan begitu banyak waktu?

@matthew-dean Tampaknya itu adalah String.prototype.split . Jika Anda membuka profil di chrome devtools Anda, Anda dapat melihat semua kode warna data. Saya mencoba mengubah profil untuk ditautkan ke https://cdn.jsdelivr.net/npm/[email protected]/dist/less.cjs.js sebagai sumbernya sehingga lebih mudah untuk memeriksa kemacetan. Apakah ada peta sumber yang tersedia untuk file *.cjs.js hingga *.js ? File https://cdn.jsdelivr.net/npm/[email protected]/dist/less.min.js.map tampaknya memetakan file .min ke sumber ES6. Mungkin kami dapat memasukkan peta sumber ke alat dev sehingga kami dapat mengetahui di mana transpilasi menyebabkan kemacetan.

Baris ini secara spesifik https://github.com/less/less.js/blob/cae5021358a5fca932c32ed071f652403d07def8/lib/less/source-map-output.js#L78 tampaknya memiliki jumlah waktu cpu yang tinggi. Tetapi mengingat operasi yang dilakukannya, itu tidak tampak aneh bagi saya.

Saya tidak memiliki banyak pengalaman dengan profil heap, tetapi hal yang menonjol bagi saya adalah peningkatan jumlah (closures), (system), (array), system / Context . Mencoba mengikatnya ke profil cpu, tampaknya peningkatan objek-objek ini menghasilkan peningkatan besar-besaran dalam waktu yang dihabiskan untuk mengumpulkan sampah.

@kevinramharak Secara umum, mengonversi AST seperti Less dengan kedalaman _n_ menjadi pohon keluaran bersambung dan rata seperti CSS melibatkan banyak pembuatan objek sementara. Jadi, apa yang mungkin terjadi adalah bahwa dengan transformasi tertentu, ia menambahkan sejumlah _x_ objek tambahan. Bahkan sementara, Anda bisa mendapatkan efek eksponensial di mana setiap node membuat bahkan hanya 2-3x objek, dikalikan dengan jumlah node dikalikan dengan berapa kali harus meratakan aturan... Saya bisa melihatnya bertambah. Kami mungkin naif secara umum untuk pada dasarnya menganggap sintaksis ES6 sebagai gula sintaksis dari sintaksis ES5. (Pengembang JavaScript mungkin bersalah dalam hal ini secara umum.) Pada kenyataannya, mengubah sintaks yang lebih baru dapat membuat pola ES5 yang tidak terlalu berkinerja. Untuk 99% pengembang, ini bukan masalah besar karena mereka tidak mengulangi kode itu ratusan atau ribuan kali per detik. Tapi ini tebakan saya tentang apa yang terjadi, karena tidak ada perubahan besar lainnya.

@kevinramharak Re: baris sumber - ini karena parser Less asli tidak melacak baris/kolom input, jadi ketika pemetaan sumber ditambahkan, pada dasarnya perlu memotong input ke dalam baris untuk mencari tahu bagaimana seharusnya memetakan ke aslinya sumber. Ini tidak akan menjadi masalah di 4.x+, tetapi masuk akal mengapa ia menghabiskan banyak waktu di sana sekarang.

Saya menggunakan less.min.js di browser dan 3.10.3 dua kali lebih lambat dari 2.7.3 yang saya gunakan sebelumnya. Baik di Chrome maupun Firefox.

@PatSmuk360 Bisakah Anda memeriksa cabang ini? https://github.com/matthew-dean/less.js/tree/3.11.0

Singkatnya, transpilasi Babel ke ES5 agak buruk, dan menggunakan banyak panggilan Object.defineProperty ke kelas transpile. Saya mengalihkan transpilasi ke TypeScript, yang memiliki output prototipe fungsi yang jauh lebih waras.

Ini semua baik-baik saja dan keren, tetapi setelah melakukan ini, tes browser Less tidak akan berjalan karena menggunakan PhantomJS yang sangat tua dan ketinggalan jaman, dan sejauh ini, tidak ada seorang pun (termasuk saya) yang berhasil memigrasikan tes dari PhantomJS ke Chrome Tanpa Kepala.

Tapi, satu masalah pada satu waktu: jika sumber dist di cabang itu tidak memiliki masalah memori, maka mungkin kita bisa mengatasi kekacauan itu yaitu pengujian browser.

Saya telah berhasil memigrasikan Lebih sedikit pengujian browser ke Chrome Tanpa Kepala, tetapi dalam hal kinerja/stabilitas, saya membutuhkan banyak umpan balik dari pengguna sebelum aman untuk digabungkan, karena mengubah pipa transpilasi sepenuhnya dari Babel ke TypeScript.

Cabang saat ini dapat ditemukan di sini: https://github.com/less/less.js/pull/3442

Masih 2x lebih lambat dari 2,7.

@alecpl Itu informasi yang bagus, tapi saya benar-benar ingin tahu apakah 3.11.0 merupakan peningkatan dari 3.10.

Hal yang aneh tentang ini adalah bahwa, _dalam teori_, kode Less asli dikonversi dengan Lebab, yang seharusnya kebalikan dari Babel. Yang berarti ES5 -> ES6 -> ES5 seharusnya hampir identik, tetapi jelas bukan itu masalahnya. Jadi saya perlu menyelidiki (kecuali ada orang lain yang punya waktu, yang merupakan dukungan yang disambut baik) bagaimana kode ES6->ES5 berbeda dari kode ES5 asli.

@alecpl

Jadi, saya telah menjalankan berbagai pengujian, dan menghabiskan waktu melakukan benchmarking 3.11.0 vs. 3.10.3 vs. 3.9.0 vs. 2.7.3 di Headless Chrome

Saya tidak menemukan bukti bahwa kompiler Less lebih lambat untuk versi apa pun, apalagi 2x lebih lambat. Mungkinkah benar bahwa 3.10.0 memiliki lebih banyak memori overhead karena pengaturan transpilasi, dan mungkin jika sistem dibatasi ruang dan melakukan lebih banyak pertukaran memori atau lebih banyak GC sebagai hasilnya, itu mungkin mengakibatkan pelambatan? Tapi saya tidak bisa memverifikasinya.

Anda dapat menguji diri Anda dengan menjalankan grunt benchmark pada cabang 3.11.0. Mereka mungkin melaporkan nomor yang berbeda pada lari individu, tetapi jika Anda berlari cukup lama, Anda akan melihat waktunya kira-kira sama. Jadi saya tidak tahu di mana Anda mendapatkan data Anda.

@PatSmuk360 Apakah Anda dapat menguji overhead memori 3.11.0?

Saya tidak membuat kode Anda sendiri. Saya tidak menggunakan nodejs. Saya hanya mengambil file less.min.js dari folder dist untuk dua versi berbeda yang saya sebutkan dan menggunakannya di halaman saya. Kemudian di konsol saya melihat pengaturan waktu dicetak oleh kode Lebih Sedikit. Kode less saya menggunakan banyak file dan file output sekitar 100kB css yang diperkecil. Itu adalah tolok ukur "kehidupan nyata". Saya sedang berbicara tentang kode Roundcube .

Chrome jauh lebih cepat daripada Firefox, tetapi perbedaan antar versi serupa.

@alecpl Hmm.... mungkin itu perbedaan khusus untuk kode Less tertentu. Memang benar bahwa patokannya sewenang-wenang. Jika saya punya waktu, saya akan menambahkan file Kurang itu ke pembandingan.

Masalah ini secara otomatis ditandai sebagai basi karena tidak ada aktivitas terbaru. Ini akan ditutup jika tidak ada aktivitas lebih lanjut yang terjadi. Terima kasih atas kontribusi Anda.

Hanya ingin memposting pembaruan cepat: Saya mencoba 3.11.1 dan sama lambatnya dengan 3.10.3. Saya akan melihat apakah saya dapat membuat tolok ukur yang representatif untuk menguji/membuat profil ini.

Saya telah meningkatkan ke 3.11.1 dan memiliki masalah konsumsi memori yang sama sekarang.
Proyek berukuran sedang membutuhkan ~600MB RAM untuk dibangun melalui webpack dan less-loader .

Saya telah mengambil jadwal alokasi tumpukan yang menghasilkan ini;

Sesuatu menyebabkan alokasi besar yang gila tetap hidup oleh Ruleset .

[EDIT]
Saya menurunkan versi ke 3,9 dan mengambil garis waktu alokasi tumpukan dari itu. Akan melihat apakah saya melihat sesuatu yang sangat berbeda.

@matthew-dean
Menemukan petunjuk untuk Anda.

Di 3.11 salah satu pengikut yang terdaftar untuk RuleSet adalah ImportManager.
Dalam 3.9 ini _tidak terjadi_.

Jika semuanya tetap hidup oleh ImportManager dan ImportManager adalah singleton di seluruh proses kompilasi. Baiklah; yang secara signifikan akan meningkatkan penggunaan memori karena tidak ada yang bisa menjadi sampah yang dikumpulkan. Bahkan aturan perantara pun tidak.

@rjgotten Hmm...... jika suatu objek memiliki referensi ke objek lain, mengapa itu mencegah GC? Maksud saya, secara teknis, semua objek menyimpan referensi ke node API publik melalui rantai prototipe. Itu hanya akan mencegah GC jika kebalikannya benar yaitu beberapa objek yang mempertahankan referensi ke setiap instance aturan.

Anda sepertinya salah paham.

Ketika "A adalah pengikut B," itu berarti A mempertahankan referensi ke B yang mencegah pengumpulan sampah B. Jadi ketika saya menulis ImportManager terdaftar sebagai pengikut Ruleset, saya mengungkapkan dengan tepat apa yang juga Anda simpulkan: ImportManager menyimpan referensi ke instance Ruleset, yang mencegah GC dari instance Ruleset tersebut.

@rjgotten Oh ya? Saya bertanya-tanya bagaimana perubahan itu terjadi di sana. Kemungkinan kuat saya yang harus disalahkan, atau ada sesuatu tentang refactor ES6 yang melakukannya. Tapi ya, itu pasti bisa! Terima kasih telah menyelidiki!

Oke, bagaimana dengan ide radikal ini.

Saya membuat cabang dengan cherry memilih semuanya KECUALI konversi ES6. Ini tidak sederhana, dan ini akan menghentikan semua itu, tetapi jika file Babelified / Typescript tidak dapat mengungguli JS asli yang ada, maka itu tidak sepadan.

Saya tidak tahu bagaimana kita akan merekonsiliasi sejarah git, tapi inilah cabang -> https://github.com/less/less.js/tree/release_v3.12.0-RC1. Nuking konversi adalah masalah besar, jadi saya pikir cabang ini akan menjadi pembandingan yang sangat solid untuk dibandingkan.

Saya bertanya-tanya bagaimana perubahan itu terjadi di sana. Kemungkinan kuat saya yang harus disalahkan, atau ada sesuatu tentang refactor ES6 yang melakukannya. Tapi ya, itu pasti bisa! Terima kasih telah menyelidiki!

Ini tentu aneh. Dari apa yang dapat saya uraikan, sepertinya ImportManager entah bagaimana berakhir sebagai pengikut untuk Ruleset melalui gluecode/polyfill yang ditambahkan oleh konversi ES6.

Saya ingin tahu apakah ada solusi di sini yang berakhir di tengah jalan. Yaitu mempertahankan ES6 build untuk Node.js tetapi juga memiliki target browser yang diubah. Akan menjadi kerugian besar untuk menghilangkan kejelasan kode yang ditambahkan oleh konversi ES6. 😢

@rjgotten

Akan menjadi kerugian besar untuk menghilangkan kejelasan kode yang ditambahkan oleh konversi ES6.

Ini mungkin tidak seburuk kelihatannya, karena dua alasan:

1. Konfigurasi rollup masih ada, dan dapat ditarik dari komit jika seseorang ingin menelitinya.
2. Saya telah aktif mengerjakan Less 4.0 berbasis TypeScript untuk beberapa waktu. Saya lebih suka menghabiskan waktu saya untuk itu daripada melacak regresi kinerja ini. Ini adalah refactor ground-up, jadi tidak dekat dengan cara apa pun, tetapi menurut sifat TS, tidak mungkin memiliki mutasi objek satu kali yang memegang referensi dan mencegah GC. Dan kodenya jauh lebih jelas untuk diikuti . Jadi ada itu.

Tampaknya _bit_ berat untuk mengembalikan semuanya ke ES5 hanya untuk memperbaiki masalah ini, tetapi dapat dimengerti mengingat penulisan ulang sedang berlangsung. Tetap saja, kita harus mempertimbangkan berapa lama kita harus hidup dengan keputusan ini. Seperti yang disebutkan @rjgotten , kami akan kehilangan banyak kejelasan kode, dan jika v4 masih jauh, maka saya akan mengatakan mari kita coba menyelidiki sedikit lebih banyak sebelum mengambil opsi nuklir ES5 — terutama karena masalah ini (sementara a yang buruk) tampaknya tidak menjadi pemecah masalah bagi sebagian besar pengguna.

Apakah ada orang yang mengalami ini yang bersedia membagikan kode mereka? Akan sangat bagus jika kita bisa melakukan benchmark menggunakan proyek dunia nyata sehingga kita bisa yakin apakah perubahan itu membantu atau tidak. Jika kita bisa mendapatkannya maka saya akan bersedia membantu mencoba dan mempersempit di mana hambatannya.

@matthew-dean, sebagai tambahan, apakah Anda mencoba mengkompilasi dengan Babel dalam mode longgar untuk melihat apakah itu menghasilkan kode yang tampak lebih waras?

@seanCodes Saya

Satu tebakan yang saya miliki adalah bahwa beberapa logika perusakan memiliki banyak boilerplate pembuatan objek.

Pada dasarnya, seseorang harus secara sukarela memiliki masalah ini.

@matthew-dean, sebagai tambahan, apakah Anda mencoba mengkompilasi dengan Babel dalam mode longgar untuk melihat apakah itu menghasilkan kode yang tampak lebih waras?

@seanCodes Kode dikompilasi menggunakan TypeScript, bukan Babel. Ide saya adalah menambahkan tipe JSDoc secara bertahap untuk membuat pengecekan tipe lebih kuat, tetapi TS di v4 sudah cukup untuk menulis ulang, saya tidak yakin apakah itu perlu. Jadi, seseorang dapat bereksperimen dengan Babel v. TypeScript (dan pengaturan yang berbeda untuk masing-masing) untuk melihat apakah Babel menghasilkan kode yang lebih berkinerja. Berhati-hatilah dengan masalah ini, yang disebabkan oleh awalnya memproduksi build non-ES5 untuk Node.js: https://github.com/less/less.js/issues/3414

@seanCodes Juga, saya masih merasa sulit untuk VERIFIKASI perbedaan kinerja. Belum ada yang menghasilkan PR/langkah-langkah untuk MEMBUKTIKAN, secara definitif, perbedaan performa. Ada sejumlah anekdot di utas ini, tetapi tanpa kode atau langkah yang dapat direproduksi, saya tidak yakin bagaimana seseorang menyelidiki ini. Idealnya, akan ada PR yang meluncurkan alat pembuatan profil (melalui debugger Chrome atau lainnya) untuk menghasilkan angka pada sistem, rata-rata pada sejumlah tes. Jadi karena ini, sejauh ini, tidak 100% dapat direproduksi, sejauh siapa pun dapat menawarkan langkah-langkah reproduksi, itu sebagian mengapa saya pribadi tidak ingin turun ke lubang kelinci itu. (Dengan kata lain, umpan balik "Saya menggunakan debugger Chrome" bukanlah serangkaian langkah reproduksi. Ini berguna untuk diketahui, tetapi tidak membantu seseorang menyelidiki. Kita perlu tahu apa yang kita lacak dan mengapa / apa hasilnya mengharapkan.)

Jadi, jika orang ingin meningkatkan Performa yang lebih sedikit menggunakan basis kode saat ini, mungkin diperlukan beberapa sukarelawan, dan satu orang untuk memiliki masalah ini.

Secara pribadi, saya belum melihat banyak perbedaan kinerja seperti pada _speed_ tetapi perbedaan dalam konsumsi memori sangat mencengangkan dan tampaknya berkorelasi dengan jumlah impor, yang tampaknya disarankan oleh analisis tumpukan sepintas saya sebagai terkait dengan masalah ini juga.

Jika itu benar, ~you~ siapa pun harus dapat menyatukan proyek uji yang layak selama itu terdiri dari banyak file yang diimpor di mana masing-masing berisi beberapa aturan, untuk melihat perbedaannya juga.

@rjgotten

Jika itu benar, Anda seharusnya dapat menggabungkan proyek uji dengan banyak file yang diimpor, masing-masing berisi beberapa aturan dan melihat perbedaannya juga.

"Anda" adalah bagian yang penting di sini. 😉

"Anda" adalah bagian yang penting di sini. 😉

Pilihan kata yang menyedihkan. Maksud saya dalam pengertian umum - yaitu "siapa pun."
Saya akan menggali lebih jauh sendiri, tetapi saya sudah memiliki terlalu banyak piring yang berputar saat ini.

@rjgotten Bisakah Anda memberi saya ide yang lebih baik tentang "banyak file yang diimpor" itu? Apakah 100 file terpisah melakukannya atau kita berbicara 1000?

Juga, bagaimana Anda pertama kali memperhatikan masalah ini? Apakah build gagal karena konsumsi memori atau apakah Anda kebetulan melihat penggunaan memori? Atau apakah Anda melihat mesin Anda melambat?

Saya belum mencoba mereplikasi ini, tetapi saya masih berharap untuk mempelajari apa yang sebenarnya harus dicari sehingga saya tidak perlu menebak-nebak.

100 atau lebih akan melakukannya. Itu kira-kira seukuran proyek kehidupan nyata yang saya perhatikan masalahnya.

Saya pertama kali menyadarinya ketika build yang berjalan di lingkungan CI perusahaan kami mulai gagal. Kami menjalankannya di dalam wadah Docker dengan batasan memori yang dikonfigurasi.

@rjgotten Apakah kita masih memiliki masalah memori pada 3.11.3? Saya menghapus semua caching (referensi) dari AST dalam impor di rilis sebelumnya, jadi jika impor ditahan, dan pohon AST ditahan di dalamnya, maka itu akan meningkatkan penggunaan memori, tetapi jika kita menjatuhkan pohon dari ditahan, apakah itu menyelesaikannya?

@matthew-dean Ya, masalahnya masih ada di 3.11.3.

Saya akan mencoba membuat bukti konsep tetapi saya punya banyak hal. Saya telah memasukkan ini ke dalam daftar tugas saya setelah saya mendapatkan waktu tambahan.

@matthew-dean Saya ingin menguji ini pada proyek yang relatif besar, yang sebelumnya gagal. Ada yang perlu saya ketahui? Haruskah saya menggunakan cabang ini, https://github.com/less/less.js/tree/release_v3.12.0-RC1 ?

@nfq Anda dapat mencobanya, tetapi kebijaksanaan yang berlaku di utas ini bukanlah untuk meledakkan konversi ES6, yang dilakukan oleh cabang itu, dan sebagai gantinya mendapatkan lebih banyak informasi untuk mendiagnosis masalah dengan benar.

Kebetulan, saya mencoba memeriksa objek less selama kompilasi dalam upaya untuk menemukan objek persisten, dan tidak dapat menemukannya. ️

Saya juga mengalami masalah kinerja. Untuk rangkaian pengujian yang sama:

| Versi | Waktu |
| -- | -- |
| v3.9.0 | ~1.6s |
| v3.10.0~v3.11.1 | ~3.6s |
| v3.11.2+ | ~12 detik |

Terlepas dari 3.9.0 → 3.10.0 yang dibahas di sini, tampaknya ada penurunan kinerja yang signifikan pada v3.11.2 . Perubahan di changelog ini tampaknya mencurigakan:

3498 Hapus cache pohon di manajer impor (#3498)

Sama untuk ku.

Pengaturan waktu untuk build yang identik (semua pada node 10.19.0):

• v3.9: 29.9 detik
• v3.10: 76.0 detik
• v3.12: 89.3 detik

@jrnail23

Apakah Anda memiliki repo yang dapat menunjukkan hasil tersebut?

@matthew-dean Saya punya satu untuk https://github.com/less/less.js/issues/3434#issuecomment -672580467: https://github.com/ecomfe/dls-tooling/tree/master/packages/ less-plugin-dls (Ini adalah monorepo, yang menyertakan plugin Less.)

Maaf, @matthew-dean, saya tidak tahu. Hasil itu dari produk majikan saya.

Hasil itu dari produk majikan saya.

Alasan yang sama saya juga tidak dapat memberikan file apa pun. 😞

@rjgotten @jrnail23 @Justineo - Hanya ingin tahu, apakah Anda memiliki sejumlah kasus di mana impor yang sama diimpor beberapa kali dalam file yang berbeda?

Dalam kasus saya, kami memiliki plugin yang menyuntikkan pernyataan @import dan menyediakan banyak fungsi khusus. File yang diimpor mengimpor bagian lain dari proyek yang pada akhirnya akan menghasilkan 1000+ Variabel lebih sedikit.

@matthew-dean, kami memiliki file base.less yang mengimpor hal-hal umum (mis., variabel warna, tipografi, dll.).
Beberapa grep cepat dari aplikasi kami menunjukkan bahwa referensi base.less (yaitu, <strong i="8">@import</strong> (reference) "../../../less/base.less"; ) diimpor oleh 66 file less khusus komponen/fitur lainnya, dan beberapa file tersebut mungkin juga mengimpor file lain yang lebih sedikit komponen/fiturnya (yang mungkin merujuk sendiri base.less ).
Menariknya, kami ternyata juga memiliki file less yang (mungkin secara tidak sengaja?) mengimpor dirinya sendiri sebagai referensi.

@rjgotten @jrnail23 @Justineo - Hanya ingin tahu, apakah Anda memiliki sejumlah kasus di mana impor yang sama diimpor beberapa kali dalam file yang berbeda?

Bagi saya, itu adalah 'ya.' Proyek yang pertama kali saya alami masalah adalah solusi skinnable yang memanfaatkan file variabel terpusat yang disertakan dalam semua yang lain. Selain itu, kami menggunakan desain berbasis komponen di mana kami memiliki pabrik mixin yang memproduksi misalnya jenis tombol tertentu, ikon font, dll. dan bagian dari itu diimpor dalam beberapa file juga.

Pada dasarnya; setiap dependen diatur untuk mengimpor dependensinya secara ketat dan kami mengandalkan kompiler Less untuk menghilangkan penipuan dan mengurutkan impor ke dalam urutan yang benar dan memastikan keluaran CSS yang benar.

@rjgotten

Saya memposting dan menghapusnya (karena saya pikir saya telah mengetahuinya, tetapi saya masih tidak dapat mereplikasinya), masih belum ada langkah untuk mereproduksi dalam apa yang dilaporkan orang, termasuk pada proses apa.

Bahkan sesuatu yang sederhana seperti ini:

Di 3.11 salah satu pengikut yang terdaftar untuk RuleSet adalah ImportManager.

Saya tidak dapat menemukan bukti tentang itu, tetapi saya juga tidak tahu bagaimana Anda dapat menentukannya. Saya tidak cukup akrab dengan Chrome DevTools untuk mengetahui bagaimana seseorang dapat menentukan hal seperti apa yang dipertahankan oleh apa, dan itu adalah topik yang cukup kabur sehingga Google tidak membantu saya. Seperti, apakah orang-orang melekat pada proses Node? Menjalankannya di browser dan mengatur breakpoints? Apa saja langkah-langkahnya?

Singkatnya, pada tahun penerbitan ini, tidak ada laporan yang memiliki langkah untuk mereproduksi. Saya yakin semua anekdot ini berarti SESUATU, tetapi bagaimana ANDA menentukan apa yang ANDA temukan? Atau dapatkah Anda memikirkan pengaturan yang akan menunjukkan ini? Saya ingin membantu mencari tahu, tetapi saya tidak tahu cara mereproduksinya.

@Justineo Di repo Anda, langkah apa yang Anda ambil untuk menentukan ukuran memori atau waktu kompilasi? Apa yang Anda gunakan untuk mengukur?

@Justineo Karena Anda menunjukkan penghapusan cache (yang mungkin merupakan ide yang buruk), dapatkah Anda menguji cabang ini dan melihat apakah itu membantu kecepatan build Anda? https://github.com/less/less.js/tree/cache-restored

Hanya untuk memberikan beberapa pembaruan pada eksperimen/pengujian hari ini:

shell:test Grunt

• Kurang 3.9 -- 1.8s
• Kurang 3,12 (Babel-transpiled ke ES5) -- 9.2s
• Kurang 3,12 (Babel-transpiled ke ES6) -- 3.1s
• Kurang 3.12 (TypeScript-transpiled ke ES5) -- 3.2s

Jadi, saya pikir panjang dan pendeknya adalah bahwa kode yang ditranskripsi selalu lebih lambat, dan kami naif untuk berpikir sebaliknya. Saya agak terkejut karena transpilasi sekarang sangat "standar" di dunia JavaScript. Apakah ada penelitian lain yang mendukung hal ini?

@Justineo Di repo Anda, langkah apa yang Anda ambil untuk menentukan ukuran memori atau waktu kompilasi? Apa yang Anda gunakan untuk mengukur?

npm run test akan menghasilkan total waktu yang telah berlalu. Dan di proyek lain kami mengalami OOM saat beralih ke 3.12.

Jika kita melihat kode yang dihasilkan TypeScript, kita mendapatkan sesuatu seperti:

Object.defineProperty(exports, "__esModule", { value: true });
var tslib_1 = require("tslib");
var node_1 = tslib_1.__importDefault(require("./node"));
var variable_1 = tslib_1.__importDefault(require("./variable"));
var property_1 = tslib_1.__importDefault(require("./property"));
var Quoted = /** <strong i="6">@class</strong> */ (function (_super) {
    tslib_1.__extends(Quoted, _super);
    function Quoted(str, content, escaped, index, currentFileInfo) {
        var _this = _super.call(this) || this;
        _this.escaped = (escaped == null) ? true : escaped;
        _this.value = content || '';
        _this.quote = str.charAt(0);
        _this._index = index;
        _this._fileInfo = currentFileInfo;
        _this.variableRegex = /@\{([\w-]+)\}/g;
        _this.propRegex = /\$\{([\w-]+)\}/g;
        _this.allowRoot = escaped;
        return _this;
    }

vs:

var Node = require('./node'),
    Variable = require('./variable'),
    Property = require('./property');

var Quoted = function (str, content, escaped, index, currentFileInfo) {
    this.escaped = (escaped == null) ? true : escaped;
    this.value = content || '';
    this.quote = str.charAt(0);
    this._index = index;
    this._fileInfo = currentFileInfo;
    this.variableRegex = /@\{([\w-]+)\}/g;
    this.propRegex = /\$\{([\w-]+)\}/g;
};

Jadi tebakan saya adalah bahwa semua definisi dan panggilan fungsi tambahan itu bertambah, seiring waktu? Kecuali ini adalah ikan haring merah, tapi saya tidak tahu apa lagi yang harus dikaitkan dengan ini kecuali transpilasi. Yang saya tidak mengerti adalah mengapa TS tidak dapat menghasilkan kode yang lebih dekat dengan aslinya.

MEMPERBARUI:

Jika saya mencoba untuk menempatkan tes 3.9 setara dengan apa yang ada di 3.12, maka pada dasarnya saya mendapatkan 1.2s vs 1.3s. Jadi saya tidak yakin lagi tentang perbedaan ini karena tes telah berubah. Itu harus dijalankan terhadap lebih sedikit file yang sama persis.

@Justineo @rjgotten Saya telah mendorong beberapa tweak TypeScript untuk membuat build yang lebih efisien. Apakah Anda ingin membangun dan mencoba cabang itu? https://github.com/less/less.js/tree/cache-restored

@matthew-dean 👍 Terima kasih! Saya akan mencobanya nanti hari ini.

Saya telah menguji cabang cache-restored dan ini jauh lebih cepat daripada v3.11.2+, dengan kecepatan yang hampir sama dengan v.3.1.0~3.11.1.

@Justineo

Saya telah menguji cabang yang dipulihkan cache dan jauh lebih cepat daripada v3.11.2+, dengan kecepatan yang hampir sama dengan v.3.1.0~3.11.1.

Yah, itu menjanjikan. Mari dapatkan umpan balik dari @rjgotten @jrnail23 dan lainnya di utas ini. Penghapusan cache itu dilakukan setelah utas ini diposting (3.11.2); sebenarnya itu adalah upaya untuk menghapus beberapa overhead memori, tetapi dalam kasus di mana Anda mengimpor file yang sama beberapa kali, itu pasti bisa memperburuk keadaan.

Jadi, singkatnya, saya masih tidak yakin tentang masalah asli atau penyebabnya (selain SESUATU yang terjadi dalam konversi kode), dan saya ingin tahu apakah cabang ini masih memiliki masalah itu, tetapi seperti yang saya sebutkan sebelumnya , tidak ada langkah repro yang jelas jadi saya tidak yakin.

@matthew-dean, saya mengalami sedikit masalah saat mencoba menggunakan cabang cache-restored (Saya tidak begitu jelas tentang apa yang perlu dilakukan untuk menggunakannya secara lokal, karena npm link gagal Aku).
Bisakah Anda memublikasikan versi canary/pra-rilis yang dapat saya coba?

@jrnail23

Saya pikir ini berhasil. Coba hapus Lebih sedikit dan instal dengan npm i [email protected]+84d40222

@matthew-dean, saya baru saja mencoba versi itu, dan itu masih buruk untuk saya.
Untuk build webpack baru (tanpa caching), dibutuhkan 62,4 detik untuk v3.9, tetapi 121 detik untuk v3.13.1.
Untuk build yang di-cache, v3.9 membutuhkan waktu 30 detik, dan v3.13.1 membutuhkan waktu 83-87 detik.

@jrnail23 Bisakah Anda mencoba menghapus semua modul simpul dan menginstal [email protected]+b2049010

Kurang 3.9 Tolok ukur:

Kurang 4.0.1-alpha.0:

Kurang 4.0.1-alpha.2:

@Justineo @rjgotten Bisakah Anda mencoba ini juga?

@jrnail23 @Justineo @rjgotten

Perhatikan bahwa ini adalah versi 4.0 sehingga Anda mungkin mengalami kesalahan jika kode Anda memiliki perubahan yang melanggar ini:

• Tanda kurung diperlukan untuk panggilan mixin (misalnya .mixin; tidak diperbolehkan)
• Mode matematika default Less sekarang adalah pembagian parens, jadi garis miring (dimaksudkan sebagai matematika) harus dalam tanda kurung

Jadi, sementara saya sekarang jauh lebih optimis bahwa saya telah memperbaiki masalah ini, berdasarkan tolok ukur terbaru, saya belum mengetahui mengapa masalah ini terjadi. Jika kinerja bertahan untuk orang lain, saya dapat memberikan ikhtisar tentang bagaimana saya akhirnya mempersempit masalah dan apa yang saya temukan. Dengan kata lain, saya pikir saya menemukan _di mana_ masalahnya, tetapi belum tentu mengapa.

Hasil dari rangkaian pengujian yang sama dengan https://github.com/less/less.js/issues/3434#issuecomment -672580467:

| Versi | Waktu |
| -- | -- |
| v3.9.0 | ~1.6s |
| v3.10.0~v3.11.1 | ~3.6s |
| v3.11.2+ | ~12 detik |
| 4.0.1-alpha.2+b2049010 | ~1.6s |

Saya dapat mengonfirmasi bahwa untuk rangkaian pengujian khusus saya, tingkat kinerja telah meningkat secepat v3.9.0. Sangat dihargai Mat! Sementara saya tidak yakin tentang perubahan istirahat pada mode matematika. Mengubah ini dapat menyebabkan kerusakan banyak aplikasi kami sehingga kami mungkin terjebak pada v3.9.0 bahkan masalah kinerja terpecahkan.

@Justineo

Sementara saya tidak yakin tentang perubahan istirahat pada mode matematika.

Anda dapat mengkompilasi secara eksplisit dalam mode math=always untuk mendapatkan perilaku matematika sebelumnya. Hanya saja defaultnya yang berbeda.

Perincian masalah

TL;DR - Waspadalah terhadap pola kelas

Masalahnya adalah dalam transpilasi kelas di Babel dan TypeScript. (Dengan kata lain, keduanya memiliki masalah kinerja yang sama dengan kode yang diubah, dengan Babel menjadi sedikit lebih buruk.) Sekarang, bertahun-tahun yang lalu, ketika pola kelas diperkenalkan, saya diberitahu--dan sampai masalah ini, percaya-- kelas itu pewarisan dalam JavaScript adalah gula sintaksis untuk pewarisan fungsional.

Singkatnya, tidak. _(Sunting: yah .... itu dan bukan. Itu tergantung pada apa yang Anda maksud dengan "warisan" dan bagaimana Anda mendefinisikannya seperti yang akan Anda lihat segera .... yaitu ada beberapa pola untuk buat "warisan" dalam rantai prototipe dalam JavaScript, dan kelas hanya mewakili satu pola, tetapi pola itu agak berbeda dari yang lain, oleh karena itu TS/Babel membutuhkan kode pembantu untuk "meniru" pola ini menggunakan fungsi khusus.)_

Lebih sedikit kode terlihat seperti ini:

var Node = function() {
  this.foo = 'bar';
}

var Inherited = function() {
  this.value = 1;
}
Inherited.prototype = new Node();

var myNode = new Inherited();

Sekarang katakan Anda ingin menulis ulang ini menggunakan JS "modern". Sebenarnya, Anda dapat mengotomatiskan proses ini, yang saya lakukan, tetapi saya akan menulisnya dengan cara yang sama, yaitu:

class Node {
  constructor() {
    this.foo = 'bar';
  }
}
class Inherited extends Node {
  constructor() {
    super();
    this.value = 1;
  }
}
var myNode = new Inherited();

Hal yang sama, kan? Sebenarnya tidak. Yang pertama akan membuat objek dengan properti { value: 1 } , dan pada rantai prototipenya, ia memiliki objek { foo: 'bar' } .

Yang kedua, karena akan memanggil konstruktor pada Inherited dan Node , akan membuat objek dengan struktur seperti { value: 1, foo: 'bar' } .

Sekarang, untuk _user_, ini sebenarnya tidak masalah, karena Anda dapat mengakses value dan foo dari myNode dalam kedua kasus tersebut. _Fungsional_, mereka tampaknya berperilaku sama.

Di sinilah saya memasukkan spekulasi murni

Dari apa yang saya ingat di artikel tentang mesin JIT seperti V8, struktur objek sebenarnya sangat penting. Jika saya membuat banyak struktur seperti { value: 1 } , { value: 2 } , { value: 3 } , { value: 4 } , V8 membuat representasi statis internal dari struktur itu. Anda pada dasarnya menyimpan struktur+data sekali, dan kemudian datanya 3 kali lagi.

TETAPI jika saya menambahkan properti yang berbeda setiap kali, seperti: { a: 'a', value: 1 } , { b: 'b', value: 2 } , { c: 'c', value: 3 } , { d: 'd', value: 4 } , maka itu adalah 4 struktur berbeda dengan 4 kumpulan data , meskipun dibuat dari kumpulan kelas asli yang sama. Setiap mutasi objek JS tidak mengoptimalkan pencarian data, dan pola kelas yang diubah menjadi fungsi menyebabkan (mungkin) mutasi yang lebih unik. (Sejujurnya saya tidak tahu apakah ini benar untuk dukungan kelas asli di browser.)

AFAIK, yang juga benar adalah bahwa semakin banyak properti yang Anda miliki pada suatu objek, semakin lama waktu pencarian properti individual.

Sekali lagi untuk pengguna akhir, ini jarang menjadi masalah karena mesin JS sangat cepat. Buuuuut mengatakan Anda memelihara mesin yang membuat dan mencari properti/metode pada BANYAK objek secepat mungkin. (Ding ding ding.) Tiba-tiba perbedaan kecil antara cara TypeScript / Babel "memperluas" objek dan pewarisan prototipe fungsional asli bertambah dengan sangat cepat.

Saya menulis implementasi tanpa tulang dari Node dan fungsi pewarisan, menggunakan sintaks Less yang lama dan pola kelas yang ditranspilasikan dengan TS. Tepat di luar gerbang, node yang diwarisi menghabiskan 25% lebih banyak memori/sumber daya, dan itu SEBELUM setiap instance dari node yang diwarisi telah dibuat.

Sekarang pertimbangkan bahwa beberapa node mewarisi dari node lain. Itu berarti, representasi kelas dalam memori mulai berlipat ganda, seperti halnya turunannya.

Sekali lagi, ini adalah spekulasi

Saya harus menekankan mengambil semua ini dengan sebutir garam, karena saya belum pernah mendengar konversi ke kelas menjadi bencana untuk kinerja. Apa yang saya _pikir_ sedang terjadi adalah bahwa ada beberapa kombinasi khusus dari pencarian objek/contoh yang Less gunakan yang secara serius tidak mengoptimalkan JIT. _(Jika beberapa ahli mesin JavaScript tahu mengapa kelas yang ditranspilasikan berkinerja jauh lebih buruk daripada metode pewarisan JS asli dalam kasus ini, saya ingin tahu.)_ Saya mencoba membuat ukuran kinerja untuk membuat ribuan objek yang diwarisi menggunakan kedua metode, dan Saya tidak pernah bisa melihat perbedaan kinerja yang konsisten.

Jadi, sebelum Anda pergi dengan "kelas dalam JavaScript buruk", mungkin ada beberapa pola lain yang sangat disayangkan di basis kode Less ditambah dengan perbedaan kelas transpiled vs JS asli yang menciptakan penurunan kinerja ini.

Bagaimana saya akhirnya mengetahuinya

Sejujurnya, saya tidak pernah curiga dengan pola kelas. Saya tahu bahwa kode ES5 asli berjalan lebih cepat daripada kode reverse-Babelified, tetapi saya mencurigai sesuatu di sekitar fungsi panah atau menyebarkan sintaks di suatu tempat. Saya masih memiliki cabang ES5 terbaru, jadi suatu hari saya memutuskan untuk menjalankan lebab lagi, dan hanya menggunakan transformasi ini: let,class,commonjs,template . Saat itulah saya menemukan itu lagi memiliki masalah kinerja. Saya tahu itu bukan templating string atau let-to-var; Saya pikir mungkin perlu-untuk-impor melakukan sesuatu jadi saya bermain dengan itu untuk sementara waktu. Itu meninggalkan kelas. Jadi pada firasat, saya menulis ulang semua kelas yang diperluas kembali ke warisan fungsional. Bam, performanya kembali.

Sebuah kisah peringatan

Jadi! Pelajaran yang dipelajari. Jika proyek Anda menggunakan kode ES5 lama, dan Anda mendambakan kebaikan "modern" Babel-ified atau TypeScripted, ingatlah bahwa apa pun yang Anda transpile, Anda tidak menulis.

Saya masih dapat menulis ulang kelas menjadi sesuatu yang lebih "seperti kelas", dengan pola yang sedikit lebih dapat dipelihara , tetapi kurang lebih mempertahankan pola pewarisan fungsional asli simpul Less, dan saya akan meninggalkan catatan yang kuat dalam proyek untuk pemelihara masa depan untuk tidak pernah melakukan ini lagi.

Anda dapat mengkompilasi secara eksplisit dalam mode math=always untuk mendapatkan perilaku matematika sebelumnya. Hanya saja defaultnya yang berbeda.

Saya sadar akan hal ini. Kami memiliki banyak basis kode Lebih sedikit di banyak tim yang berbeda, sehingga mengubah perubahan bahkan dalam opsi kompilasi default akan meningkatkan biaya komunikasi. Saya tidak yakin apakah manfaatnya sepadan dengan kerusakannya.

Terima kasih atas rinciannya!

Saya melihat penggunaan Object.assign dalam output yang dikompilasi, yang berarti itu hanya berfungsi di browser yang mendukung sintaks ES class kecuali polyfill sekarang diperlukan. Jadi dapatkah kita menggunakan sintaks asli tanpa mengubahnya ke ES5 jika kita bermaksud untuk menghentikan dukungan untuk lingkungan yang lebih lama (mis. IE11, Node 4, ...)?

Pada saat yang sama, saya pikir lebih baik jika kita dapat memisahkan perbaikan penurunan kinerja dan perubahan yang melanggar, yang berarti mendaratkan perbaikan kinerja di v3 dan memasukkan perubahan yang melanggar hanya di v4.

@matthew-dean
Fakta bahwa kelas ES adalah pelakunya gila menakutkan.
Terima kasih atas perincian yang rumit.

Pergi untuk menunjukkan: _komposisi atas warisan_

Meskipun FYI; jika Anda menginginkan rantai pewarisan protypal yang lebih bersih, Anda benar-benar harus melakukannya sedikit berbeda dari contoh Anda.
Jika Anda menggunakan Object.create seperti ini:

var Node = function() {
  this.foo = 'bar';
}
Node.prototype = Object.create();
Node.prototype.constructor = Node;

var Inherited = function() {
  Node.prototype.constructor.call( this );
  this.value = 1;
}
Inherited.prototype = Object.create( Node.prototype );
Inherited.prototype.constructor = Inherited;

var myNode = new Inherited();

kemudian Anda meratakan properti ke instance itu sendiri yang kemudian berbagi bentuk yang sama; prototipe berbagi bentuk; _dan_ Anda tidak perlu merayapi rantai prototipe untuk setiap akses properti. 😉

@Justineo

Saya melihat penggunaan Object.assign dalam output yang dikompilasi, yang berarti itu hanya berfungsi di browser yang mendukung sintaks kelas ES asli kecuali polyfill sekarang diperlukan. Jadi dapatkah kita menggunakan sintaks asli tanpa mengubahnya ke ES5 jika kita bermaksud untuk menghentikan dukungan untuk lingkungan yang lebih lama (mis. IE11, Node 4, ...)?

Saya tidak berpikir itu benar yaitu Object.assign mendarat sesaat sebelum implementasi kelas tetapi poin Anda diambil. Saya hanya berharap untuk tidak menulis [Something].prototype.property berulang-ulang :/

Secara teknis, semuanya masih transpiling, jadi saya tidak tahu. Tujuan awalnya adalah basis kode yang lebih dapat dipelihara/dibaca. Jika Anda membutuhkan polyfill Object.assign di beberapa lingkungan, biarlah. Itu akan berada pada versi sesuatu yang Less tidak mendukung.

Pada saat yang sama, saya pikir lebih baik jika kita dapat memisahkan perbaikan penurunan kinerja dan perubahan yang melanggar, yang berarti mendaratkan perbaikan kinerja di v3 dan memasukkan perubahan yang melanggar hanya di v4.

Saya sudah memikirkan itu, dan saya rasa itu juga poin yang adil. Saya hanya mencoba membuat kepala saya tidak meledak membangun / memelihara 3 versi utama Less.

@rjgotten AFAIK itulah yang seharusnya dilakukan oleh pola kelas, persis seperti yang Anda definisikan. Kecuali saya tidak melihat perbedaan kritis. Jadi ️ . Saya tidak akan mencoba mengubah pola pewarisan Less's Node lagi jika kinerjanya baik (selain saya dapat menghapus panggilan Object.assign seperti yang disarankan @Justineo .)

@Justineo @rjgotten Bisakah Anda mencoba ini: [email protected]+b1390a54

Baru saja mencobanya:

| Versi | Waktu |
| -- | -- |
| v3.9.0 | ~1.6s |
| v3.10.0~v3.11.1 | ~3.6s |
| v3.11.2+ | ~12 detik |
| 4.0.1-alpha.2+b2049010 | ~1.6s |
| 3.13.0-alpha.10+b1390a54 | ~4.7s |

hal. Diuji dengan Node.js v12.13.1.

aku.... apa.

Tidak punya waktu untuk mengatur tolok ukur terpisah.
Namun dari perspektif uji integrasi, inilah beberapa angka dunia nyata: hasil kumulatif dari proyek Webpack tingkat produksi yang menggunakan Less.

Versi | Waktu | Memori Puncak
:------------------------|--------:|------------:
3.9 | 35376 md | 950MB
3.11.3 | 37878ms | 920MB
3.13.0-alpha.10+b1390a54 | 34801ms | 740MB
3.13.1-alpha.1+84d40222 | 37367ms | 990MB
4.0.1-alpha.2+b2049010 | 35857 md | 770MB

Bagi saya 3.13.0 memberikan hasil _terbaik_...

3.11.3 juga tampaknya tidak memiliki penggunaan memori pelarian yang saya lihat sebelumnya dengan versi 3.11.1.
Tetapi versi beta 4.0.1 dan 3.13.0 masih lebih baik.

3.13.1 yang memulihkan cache tidak membantu meningkatkan waktu kompilasi dunia nyata saya dan hanya meningkatkan penggunaan memori.

@rjgotten Ya, saya pikir masalahnya adalah, di utas ini, orang mengukur hal yang berbeda, dan setiap orang sejauh ini pada dasarnya memiliki data pribadi yang tidak mungkin direplikasi (tanpa mengirimkan tolok ukur Kurang, atau menerjemahkannya ke dalam PR). Less memang memiliki tes benchmark, yang dapat saya gunakan terhadap klon repo yang berbeda, untuk memverifikasi sendiri perbedaan dalam waktu parse/eval, tetapi di mana caching tidak (saat ini) berlaku.

Berikut adalah build yang diterbitkan dengan perubahan warisan di pohon, dan dengan cache pohon parse dipulihkan: [email protected]+e8d05c61

Kasus cobaan

https://github.com/ecomfe/dls-tooling/tree/master/packages/less-plugin-dls

Hasil

| Versi | Waktu |
| -- | -- |
| v3.9.0 | ~1.6s |
| v3.10.0~v3.11.1 | ~3.6s |
| v3.11.2+ | ~12 detik |
| 4.0.1-alfa.2| ~1.6s |
| 3.13.0-alfa.10| ~4.7s |
| 3.13.0-alpha.12 | ~1.6s |

Versi Node.js

v12.13.1

Bagi saya versi ini tampaknya bekerja dengan sempurna. Saya akan meminta rekan saya untuk mencoba dan memverifikasi.

Bekerja sedikit lebih buruk daripada alpha.10 untuk saya, tetapi bisa juga hanya varians:

Versi | Waktu | Memori Puncak
:------------------------|--------:|------------:
3.9 | 35376 md | 950MB
3.11.3 | 37878ms | 920MB
3.13.0-alpha.10+b1390a54 | 34801ms | 740MB
3.13.0-alpha.12+e8d05c61 | 36263ms | 760MB
3.13.1-alpha.1+84d40222 | 37367ms | 990MB
4.0.1-alpha.2+b2049010 | 35857 md | 770MB

@matthew-dean, sepertinya kode saya belum kompatibel dengan perubahan 4.0.1-alpha.2+b2049010 . Saya akan melihat apakah saya dapat menyelesaikan masalah saya dan mencobanya.

@rjgotten Ya, perbedaannya tampaknya kecil untuk kasus uji Anda.

Saya pikir hasil dari ini adalah bahwa saya mungkin mempersiapkan rilis 3.x dan 4.0. Saya tidak ingin mendorong 4.0 dengan masalah ini belum terselesaikan. Syukurlah, sepertinya sudah.

Item lain yang akan saya lakukan adalah membuka masalah bagi siapa saja untuk mengambil yang dimasukkan ke dalam pipa CI yang gagal Kurang jika jatuh di bawah ambang batas patokan tertentu.

@jrnail23 Akan sangat bagus jika Anda dapat memodifikasi untuk menjalankan 4.0 alpha, tetapi dapatkah Anda sementara mencoba [email protected]+e8d05c61 ?

@matthew-dean, saya mendapatkan yang berikut untuk build saya:

• v3.9: 98 detik
• v3.10.3: 161 detik
• v3.13.0-alpha.12: 93-96 detik

Jadi sepertinya Anda kembali ke tempat yang Anda inginkan! Kerja bagus!

Kerja bagus!

Ya, saya akan menjadi yang kedua; ketiga; dan keempat itu.
Ini adalah regresi kinerja yang buruk dan buruk yang benar-benar membutuhkan _banyak_ upaya untuk membersihkannya.

Pekerjaan _sangat baik_ selesai.

Oke tim! Saya akan menerbitkan versi 3.x, dan beberapa saat kemudian, mungkin minggu depan, menerbitkan 4.0. Keduanya sekarang harus memiliki perbaikan kinerja. Terima kasih kepada semua orang yang membantu debug!

Omong-omong, saat ini saya sedang dalam proses mengonversi basis kode Less.js ke TypeScript, dan berencana untuk menggunakan kesempatan ini untuk melakukan penyetelan / refactoring kinerja. Saya terbuka untuk membantu jika ada yang tertarik! https://github.com/matthew-dean/less.js/compare/master...matthew-dean :next

Sesuatu yang spesifik di mana Anda lebih suka mata ekstra? PR-nya sangat besar, jadi saya tidak tahu harus mulai dari mana

@kevinramharak Itu pertanyaan yang wajar. Sejujurnya, saya mengalami hambatan yang tidak terduga dengan mengonversi ke TypeScript (kesalahan yang menjadi sulit untuk diselesaikan), dan sekarang saya berpikir ulang untuk melakukannya sama sekali. Kurang berjalan dengan baik seperti itu, dan banyak alasan saya ingin mengonversi (untuk membuat refactoring/menambahkan fitur bahasa baru lebih mudah) sekarang tidak relevan karena saya telah memutuskan untuk memindahkan ide saya untuk fitur bahasa baru ke pra- bahasa pemrosesan. Saya tidak ingin terlalu mempromosikan diri sendiri, jadi DM saya di Twitter atau Gitter jika Anda ingin detailnya.