Aws-lambda-dotnet: Performa C# Lambda vs. Node vs. Python

Performa adalah sesuatu yang akan terus kami kerjakan dengan Lambda dan semua runtime yang didukung. Setiap bahasa akan memiliki kelebihan dan kekurangannya masing-masing, itulah sebabnya kami memiliki perang bahasa yang menyenangkan :)

Tes ini hanya mengukur waktu startup runtime bahasa yang merupakan sesuatu bahasa dinamis seperti Node.js dan Python selalu lebih cepat dibandingkan dengan bahasa statis seperti C# dan Java karena kurangnya pengecekan tipe dan pemuatan dependensi yang lebih lambat.

Maaf saya tidak bermaksud menutupnya. Jangan ragu untuk melanjutkan percakapan.

Terima kasih untuk menjaga ini tetap terbuka. Tidak dimaksudkan sebagai kritik, tetapi sebagai landasan untuk diskusi terbuka.

Dalam tanggapan Anda, Anda menyebutkan bahwa tes mengukur waktu startup bahasa. Saya ingin mendapatkan kejelasan lebih lanjut tentang pernyataan ini. Saya pikir pada hit pertama, aplikasi disediakan (jika perlu) dan kemudian diluncurkan, tetapi pada hit berikutnya, itu memanas. Jika dijalankan setiap saat, maka tidak ada gunanya memindahkan kode run-once (misalnya membaca nilai konfigurasi) ke dalam konstruktor dari kelas handler karena kode tersebut dibuat pada setiap pemanggilan. Bukan itu yang saya pahami dari presentasi re:Invent Anda. Bisakah Anda mengklarifikasi. Terima kasih!

Hanya untuk mengonfirmasi pemahaman saya, saya membaca ulang cara kerja wadah Lambda di sini: http://docs.aws.amazon.com/lambda/latest/dg/lambda-introduction.html

@bjorg @normj dokumentasinya cukup kabur dalam hal ini :(
Saya telah memberikan umpan balik di bawah ini dan berharap itu akan diklarifikasi

• 'Bagaimana kita bisa membuatnya lebih baik?
  tepatnya di mana waktu sebenarnya untuk 'beberapa waktu' dapat dicari untuk pernyataan: 'AWS Lambda mempertahankan wadah selama beberapa waktu untuk mengantisipasi pemanggilan fungsi Lambda lainnya.'
• Apa yang sedang Anda coba lakukan?
  tidak mengerti berapa lama kemungkinan penggunaan kembali wadah benar-benar terjadi untuk memprediksi kinerja

@bjorg apa yang Anda posting di sini bukanlah _waktu startup dingin_ Lambda. Tapi _warm response time_.

Ketika fungsi C# pertama kali dijalankan dari dingin, diperlukan waktu hingga beberapa ratus milidetik (dalam kasus saya ini 500ms). Setelah dihangatkan, itu akan tetap hidup dan melayani permintaan dengan kecepatan yang lebih cepat mirip dengan yang Anda posting (dalam kasus saya itu sekitar 0,9 hingga 1 ms). Akhirnya akan mati di akhir masa pakainya, atau penskalaan otomatis terjadi dan lebih banyak lambda dingin dimulai. Untuk mendapatkan waktu mulai, tunggu sekitar 15 menit, lalu klik Uji.

Jadi ya, Anda masih memasukkan sesuatu ke dalam konstruktor. Karena Anda tidak mendapatkan Lambda baru setiap kali Anda mengklik Uji. Tetapi Anda akan mendapatkan Lambda baru jika Anda mengklik hanya sekali dalam satu jam.

Dalam hal pengoptimalan, untuk _waktu startup dingin_ Anda dapat:

1. pastikan selalu ada request yang masuk, 24x7 agar lambda anda selalu hangat
2. siapkan ping berkala pada lambda Anda (baik jadwal cloudwatch atau newrelic atau semacamnya), sehingga lambda Anda selalu hangat.

Untuk _warm response time_ sebenarnya tidak banyak gunanya mengoptimalkan:

1. waktu respons manusia yang dapat diterima secara umum adalah 200ms
2. kurang dari 1 ms sebenarnya cukup bagus. Anda jarang mendapatkan tarif ini di luar helloworld atau toUpper .
3. Jika Anda meletakkan API Gateway di depan lambda Anda dan mengekspos panggilan HTTP ke dunia. Panggilan cache rata-rata dari web akan menjadi sekitar 50ms.
4. AWS tetap menagih Anda hingga interval 100 md
5. 0.85ms mungkin mendekati kinerja mentah kode C# bagian normal. Coba jalankan fungsi Anda di mesin Anda di dalam metode utama dan lihat.

Juga jangan bingung kinerja dengan waktu respons. Hanya karena Node merespons dalam 20 ms ketika Anda mengklik secara berurutan secara manual, tidak berarti itu akan berperilaku dengan cara yang sama ketika ada 100 ribu permintaan otomatis yang membanjiri per detik, dan meningkat setiap detik. Lakukan beberapa tes konkurensi dan beban nyata. Anda mungkin menemukan bahwa bahasa multi-utas seperti Java atau C# dapat menangani lebih banyak permintaan per detik saat dimuat. Saya benar-benar melihat statistik lambda di suatu tempat: Python = startup dingin tercepat, Java = permintaan hangat tercepat per detik, tetapi tidak dapat menemukannya sekarang.

Bagaimanapun, ini harus menjawab pertanyaan Anda semoga.

menemukan diskusi yang berisi benchmark https://www.quora.com/Which-language-better-suits-for-AWS-Lambda

@yunspace , terima kasih atas penulisan terperincinya. Saya sangat ingin tahu bagaimana implementasi .NET Core saat ini menyusun data dari permintaan internal mentah ke penangan C#. Karena pawang dapat bervariasi dalam tanda tangan (baik berdasarkan jenis dan jumlah argumen), saya akan menganggap itu dipanggil melalui refleksi. Jadi pertanyaan saya pada dasarnya adalah apakah ada cara untuk dipanggil tanpa menyentuh lapisan marshaling. Misalnya, tanda tangan Foo(Stream, ILambdaContext) dapat berupa pola penangan yang telah ditentukan sebelumnya yang melewati logika apa pun untuk mengonversi muatan ke instans POCO.

Sayangnya, kode permintaan tidak tersedia untuk diperiksa, jadi saya tidak tahu apakah itu bisa dioptimalkan lebih lanjut. Saya berharap doa hangat menjadi sangat dekat dalam kinerja dengan runtime lainnya.

Untuk un-marshalling input mentah JSON ke POCO, secara default lambdas menggunakan Amazon.Lambda.Serialization.Json yang bergantung pada Newtownsoft Json.Net yang populer. Tetapi Anda dapat menukar implementasi default ini dengan serializer Anda sendiri. Lihat bagian Penanganan Tipe Data Standar

Saya mengerti apa yang kamu maksud. Kebanyakan serializer (termasuk Json.Net) menggunakan refleksi yang lambat. Untuk membuktikan teori ini, saya kira Anda dapat melihat apakah Foo(Stream, ILambdaContext) memberi Anda waktu respons yang lebih baik untuk permintaan hangat. Dan jika demikian, maka mungkin bermanfaat untuk menggulung serializer pelanggan Anda sendiri untuk string dan POCO.

Sebenarnya, saya tidak berbicara tentang deserializer data, tetapi metode yang memanggil handler lambda. Karena pengendali lambda dapat memiliki tanda tangan yang berbeda (baik dalam jenis dan jumlah argumen), metode yang memanggilnya harus bergantung pada refleksi. AFAIK, tidak ada cara untuk menulis handler lambda sedemikian rupa sehingga mesin kenyamanan ini dilewati.

Saya baru-baru ini melakukan beberapa pengujian ini dan menemukan serializer benar-benar tidak membuat dampak yang besar. Faktanya, menghapus hampir semua bagian yang bergerak dan mengembalikan data statis atau hanya aliran kosong, sepertinya yang terbaik yang bisa Anda dapatkan adalah sekitar 0,85 ms pada fungsi warm. Saya menduga kode yang menjalankan fungsi C# cenderung disalahkan dan tampaknya hanya dapat dialamatkan oleh tim lambda ( @normj ).

Untuk semua runtime lainnya, termasuk Java, Anda bisa mendapatkan antara 0,22 - 0,30 ms pada fungsi warm. Pada dasarnya berarti overhead doa lambda 3x-4x lebih buruk untuk C#.

Meskipun saya setuju bahwa ini tidak menceritakan keseluruhan cerita karena C# kemungkinan akan lebih cepat dalam melakukan pekerjaan nyata, kerangka kerja overhead ini layak untuk dilihat. Saya berasumsi beberapa di antaranya dapat dikaitkan dengan hanya itu yang baru dan kinerja belum menjadi prioritas terbesar. Juga bau seperti refleksi berlebihan tanpa beberapa jenis caching bisa disalahkan.

Saya menduga juga bahwa ini karena kode awal. Saya berharap kami dapat melihat seperti apa tampilannya sehingga kami dapat membantu mengoptimalkannya. Atau, memiliki pengait tingkat rendah untuk bereksperimen juga akan membantu.

Saya juga berharap kami bisa membantu. Saya berada di ujung tanduk hanya menunggu untuk membuat inti C# bekerja dengan berbagai cara. Ini adalah faktor penentu penting antara Azure dan Amazon. Pendekatan server less C# jauh lebih baik daripada harus memelihara beberapa mesin EC2 dengan pembaruan Windows, pemeriksaan kinerja, pembaruan SQL, dan sebagainya. Ini hampir merupakan pekerjaan penuh waktu yang menjaga lingkungan ini tetap mutakhir untuk klien.

Pendekatan server less C# lebih hemat biaya, lebih sedikit tenaga kerja, secara otomatis dapat diskalakan dan dapat digunakan kembali.

Satu-satunya masalah luar biasa lainnya adalah pendekatan RDC terukur yang hemat biaya sekarang :-)

Saya telah meneruskan utas ini ke tim layanan untuk melihatnya. Saya kebanyakan memelihara alat klien seperti perpustakaan ini dan integrasi Visual Studio jadi saya tidak bisa berbicara banyak tentang apa yang terjadi di sisi layanan. Saya dapat memberi tahu Anda dalam pandangan saya yang terbatas tentang kode layanan bahwa penggunaan refleksi dioptimalkan tetapi selalu ada faktor lain yang perlu diperhatikan.

@genifycom pemahaman saya adalah utas ini melacak perbedaan kinerja 0,5 ms untuk permulaan yang hangat dibandingkan dengan runtime lainnya. Karena Lambda menagih dalam peningkatan 100 md, apakah perbedaan kinerja ini menghalangi penggunaan Anda? Saya tidak mencoba untuk mengurangi pentingnya memahami perbedaan ini, tetapi area besar yang sedang dikerjakan tim Lambda untuk meningkatkan kinerja saat ini adalah waktu mulai yang dingin.

Untuk memperjelas, ini tidak menghentikan adopsi C# Lambda kami (atau LambdaSharp, seperti yang kami namakan). Ini lebih merupakan sumber kebanggaan. :)

Sangat mengerti!

Tidak yakin apakah ini tempat yang tepat, tetapi kami sedang membangun backend web di C# saat ini, dan kami memiliki waktu mulai dingin beberapa detik, terkadang hingga sepuluh atau bahkan lebih. Setelah pukulan pertama itu, semuanya baik-baik saja. Apakah ini masih normal untuk proyek C# non-sepele, atau adakah yang bisa kita lakukan untuk menguranginya? Kami senang bisa bekerja di ekosistem .NET yang sudah kami kenal, tetapi ini membuat kami pusing.

Saya berasumsi bahwa itu ada hubungannya dengan paket eksternal yang kami sertakan dalam proyek dan bagaimana mereka ditangani oleh Amazon selama awal yang dingin, karena proyek kosong tampaknya jauh lebih baik. Saya berharap seseorang bisa menjelaskan ini.

@normj Apakah ada pembaruan tentang masalah kinerja yang kami lihat?

@SpoonOfDoom Apakah Anda melihat saran untuk memukulnya setiap 10 menit atau lebih? Itu praktik yang cukup standar di .Net selamanya, di tahun 90-an itu membuat bisnis hosting saya menjadi yang tercepat mengetahui bahwa sementara tidak ada orang lain yang melakukannya - Tapi itu sangat umum lagi dan bahkan alat umum seperti ini - https://www.iis.net/downloads /microsoft/application-initialization - yang direkomendasikan. Lambda mengubah model biaya tetapi sampai taraf tertentu tantangan yang sama dihadapi terlepas dari bagaimana mereka merekayasanya.

@bitshop Itulah yang kami lakukan saat ini. Kami memanggil semuanya sekali setiap 10 menit, dan untuk sebagian besar waktu itu membantu. Namun kami masih memiliki beberapa lonjakan setiap beberapa jam, di mana kami memulai lagi dengan dingin - tampaknya instans AWS yang menjalankan .Net Lambdas memiliki masa pakai maksimum dan kemudian yang baru digunakan terlepas dari status panas/dingin saat ini? Saya tidak yakin.
Sepertinya keputusan aneh oleh Amazon untuk tidak memberi pengembang kesempatan untuk sepenuhnya melindungi dari ini (setidaknya dengan harga tertentu). Tentu, kami hanya mencapai puncaknya setiap beberapa jam sekarang, tetapi jika terkena pelanggan alih-alih skrip kami, pelanggan masih akan terganggu dan menganggap aplikasi kami tidak dapat diandalkan dan/atau lambat.

@yunspace Sepertinya fungsi lambda template masih membutuhkan waktu startup dingin lebih dari 2000ms.
REPORT RequestId: d1e5f56c-0ea9-11e7-bb5d-bb039f76a793 Duration: 2120.69 ms Billed Duration: 2200 ms

@normj Adakah yang saya lakukan salah?

Pembaruan: Jadi saya menemukan bahwa jika fungsi mengambil input string , waktu startup akan ~800ms, tetapi jika saya benar-benar memilih jenis lain untuk itu, itu akan menjadi lebih dari 2000ms.

    // 800ms
    public string FunctionHandler(string input, ILambdaContext context)

    // 2000ms, Request being the other object type
    public string FunctionHandler(Request input, ILambdaContext context)

Saya memiliki waktu startup dingin ~21 detik dalam 128MB untuk dua fungsi lamba yang berbeda di C#, keduanya menerima SNS. Saya mendapatkan waktu yang hampir bersamaan dengan S3 put trigger vs SNS. Hangat, ini ~2 detik.

Jika saya menaikkan memori hingga 256M, saya melihat waktu cod turun menjadi sekitar ~ 10 detik, dll.

Log Lambda menunjukkan bahwa saya menggunakan memori total 40MB.

Dari salah satu fungsi, total runtime:

128MB dingin: Durasi LAPORAN: 21775,92 md Durasi Tertagih: 21800 md Ukuran Memori: 128 MB Memori Maks yang Digunakan: 35 MB

128MB hangat: Durasi LAPORAN: 1326,76 md Durasi Tertagih: 1400 md Ukuran Memori: 128 MB Memori Maks yang Digunakan: 37 MB

256MB dingin: Durasi LAPORAN: 11159,49 md Durasi Tagihan: 11200 md Ukuran Memori: 256 MB Memori Maks yang Digunakan: 39 MB

256MB hangat: Durasi LAPORAN: 792,37 md Durasi Tertagih: 800 md Ukuran Memori: 256 MB Memori Maks yang Digunakan: 39 MB

384MB dingin: Durasi LAPORAN: 7566,07 md Durasi Tagihan: 7600 md Ukuran Memori: 384 MB Memori Maks yang Digunakan: 43 MB

384MB hangat: Durasi LAPORAN: 850,59 ms Durasi Tertagih: 900 ms Ukuran Memori: 384 MB Memori Maks yang Digunakan: 47 MB

hanya untuk tertawa:

1024MB dingin: Durasi LAPORAN: 3309,12 md Durasi Tertagih: 3400 md Ukuran Memori: 1024 MB Memori Maks yang Digunakan: 38 MB

1024MB hangat: Durasi LAPORAN: 677.57 ms Durasi Tertagih: 700 ms Ukuran Memori: 1024 MB Memori Maks yang Digunakan: 41 MB

Itu banyak overhead untuk startup dingin.

Sebagai perbandingan, inilah fungsi nodejs yang melakukan sekitar setengah pekerjaan (versi lama sebelum port ke C#), tetapi jenis pekerjaan yang sama (mengambil SNS, menulis sesuatu ke database, menyimpan sesuatu ke S3) tetapi ini tampaknya benar di seluruh papan dengan fungsi lain yang kami miliki:

128MB Dingin: Durasi LAPORAN: 262,58 md Durasi Tagihan: 300 md Ukuran Memori: 128 MB Memori Maks yang Digunakan: 19 MB

128MB Hangat: Durasi LAPORAN: 134,79 md Durasi Tagihan: 200 md Ukuran Memori: 128 MB Memori Maks yang Digunakan: 19 MB

Persentase overhead saat dingin tampaknya jauh lebih masuk akal.

Saya menggunakan alat Visual Studio AWS untuk mengunggah bundel - kode sudah dikompilasi sebelumnya untuk platform target sebelum diunggah, bukan? Apakah ada sesuatu yang saya lewatkan atau ini normal? Angka-angka lain yang dilaporkan di sini lebih kecil tetapi saya tidak tahu alokasi memori.

Waktu boot yang dingin menjadi masalah saat membuat bot Slack, karena waktu Slack habis setelah 3.000 md. Sangat berharap ada cara untuk menjamin sebuah instance selalu tersedia.

Saya telah membuka tiket dukungan teknis tentang masalah ini. Jika saya belajar sesuatu yang bermanfaat, saya akan membagikannya di sini.

sementara ada banyak solusi untuk menjaga lambda tetap hangat melalui ping cloudwatch dll, pada akhirnya waktu mulai yang dingin harus menjadi sesuatu yang nyaman bagi Anda. Anda dapat mengoptimalkan start dingin tetapi tidak dapat menghindarinya. Cukup yakin ketika penskalaan otomatis terjadi, lambda baru juga akan ditingkatkan dari dingin.

@bjorg untuk menjamin instance selalu tersedia, mungkin lebih baik untuk mempertimbangkan EC2 atau ECS

@InsidiousForce Saya terkejut Anda mendapatkan awal yang dingin selama 21 @SpoonOfDoom

@yunspace sesat! :)

Oke, setelah lama bolak-balik dengan staf dukungan teknis yang ramah di Amazon, kesimpulan dasar dari percakapan ini adalah ini:
Anda dapat mencoba untuk mengoptimalkan kode Anda - mengurangi ukuran file, membuang perpustakaan yang tidak mutlak diperlukan, mencoba untuk memiliki sesedikit mungkin statis dan hal-hal lain yang diinisialisasi saat startup mungkin, dan tentu saja meningkatkan memori yang dialokasikan untuk meningkatkan daya CPU, seperti yang dibahas di utas ini. Menjaga agar Lambda tetap hidup dengan memanggilnya secara teratur dapat mengatasi masalah, tetapi tidak menghilangkannya. Interval 4 menit tampaknya menjadi nilai terbaik untuk sebagian besar kasus, tetapi tampaknya perilaku yang mendasarinya tidak sepenuhnya deterministik, jadi itu bukan aturan yang dapat diandalkan. Dan bahkan kemudian, itu tidak sepenuhnya menghilangkan masalah.

Intinya, sayangnya, adalah Anda hanya bisa sampai sejauh ini dengan melakukan semua ini, dan pada titik tertentu alokasi lebih banyak memori berhenti menjadi layak. Anda akan selalu memiliki waktu mulai yang dingin ini, dan meskipun Anda mungkin dapat menguranginya, Anda mungkin tidak akan dapat menguranginya ke titik di mana masuk akal untuk API yang menghadap publik atau semacamnya - tampaknya jika Anda tidak bisa hanya menunggu sesekali, maka C# Lambda bukan untuk Anda, dan Anda lebih baik dengan instance EC2 atau mungkin (seperti yang kita lakukan sekarang) Elastic Beanstalk, jika Anda ingin penerapan yang mudah dan penskalaan otomatis .
Kami sekarang mengonversi Lambdas kami menjadi proyek api web ASP.NET, yang memungkinkan kami untuk tetap melakukan penerapan yang nyaman dari Visual Studio dan menyimpan beberapa opsi penskalaan otomatis.

TL; DR: Sepertinya tidak ada cara yang dapat diandalkan untuk mengatasi masalah ini. Gunakan EBS atau EC2 sebagai gantinya.

Tutup karena tidak ada aktivitas. Juga repo ini sebagian besar untuk mendukung pustaka dan alat klien. Tempat yang lebih baik untuk diskusi ini adalah forum Lambda tempat tim layanan Lambda memantau.

Halo semuanya!
Saya membuat artikel di mana saya membandingkan Python vs PHP vs Java vs Ruby vs C#.
Bisakah Anda memeriksanya dan mengatakan pendapat Anda tentangnya? (Ini bukan materi teknis murni, tetapi lebih umum untuk pemula)
https://www.cleveroad.com/blog/python-vs-other-programming-languages

Artikel ini tidak membantu saya.

Pertama, itu bukan perbandingan. Judul di halaman itu mengatakan "KEUNTUNGAN MENGGUNAKAN PYTHON DARI BAHASA LAIN" jadi jelas BUKAN perbandingan.

Kedua, TIDAK ADA SATU BAHASA YANG COCOK DENGAN SEMUA PERSYARATAN!

Misalnya, membangun kerangka kerja yang kompleks dengan bahasa skrip sangat sulit. Maksud Anda tentang Python seperti dalam "Kita dapat mengatakan bahwa Python adalah bahasa minimalis. Sangat mudah untuk menulis dan membaca. Dan ketika saatnya untuk memikirkan suatu masalah, pengembang dapat fokus pada masalah tersebut, bukan pada bahasa dan sintaksnya." bahkan tidak mulai membantu dengan model kaya dan interaksi antara komponen model.

Meskipun kami tampaknya telah berpikir bahwa layanan mikro akan menjawab segalanya, saya telah berada dalam permainan ini cukup lama untuk mengetahui bahwa itu adalah pendekatan yang sangat naif.

Masalah datang dalam BANYAK bentuk.

Saya setuju dengan genifycom. Selain itu, ada beberapa poin yang tampaknya meragukan jika tidak salah. Misalnya, mengatakan bahwa Anda tidak dapat melakukan aplikasi berbasis jaringan (saya berasumsi itu berarti komputasi terdistribusi?) dengan Python tampaknya tidak mendapat informasi , dan menyatakan bahwa C# tidak memiliki banyak perpustakaan yang tersedia adalah pernyataan yang aneh mengingat ada sekitar 100 ribu paket yang tersedia di Nuget saja .
Selain itu, Python tidak memiliki "satu cara untuk menyelesaikan masalah" - selalu ada banyak cara untuk menyelesaikan masalah, dan itu biasanya tidak ada hubungannya dengan bahasa sama sekali.
Lalu ada satu bagian di mana Anda tampaknya bertentangan dengan diri Anda sendiri, di mana Anda mengatakan dalam bagan Anda bahwa Python tidak dapat melakukan aplikasi lintas platform (ya? Tampaknya salah) dan kemudian dalam teks "Python kompatibel dengan hampir semua sistem operasi modern" .
Ada juga masalah lain yang lebih kecil - misalnya, Anda secara teoritis dapat membuat kode dalam C# dengan Notepad dan mengkompilasi melalui baris perintah, tidak diperlukan IDE, sementara IDE yang tepat seperti IntelliJ juga membuat pengembangan Python jauh lebih mudah.

Selain semua itu, saya tidak yakin bahwa masalah GitHub dengan hampir satu tahun tidak aktif adalah cara yang tepat untuk mengiklankan blog Anda.

genifycom dan SpoonOfDoom Terima kasih atas pendapat Anda, saya akan mempertimbangkannya.

Berikut pendapat lain yang lebih menguntungkan untuk .Net Core:
https://read.acloud.guru/comparing-aws-lambda-performance-of-node-js-python-Java-c-and-go-29c1163c2581

Adakah tip tentang cara membuat kode c# lebih efisien dari perspektif .NET untuk penangan lambda?
Beberapa contoh pertanyaan yang saya coba jawab:
1) Akankah membuat fungsi lambda statis meningkatkan penggunaan kembali konteks Lambda dan meningkatkan kinerja?
2) Jika saya membuat kelas Fungsi (yang memiliki semua penangan lambda) kelas tunggal, apakah itu akan meningkatkan kinerja?
3) Jika saya membuat variabel konstan/hanya-baca dan membagikannya ke seluruh fungsi lambda, apakah itu akan meningkatkan kinerja?

Jika ada yang punya informasi, mohon sarannya

@niraj-bpsoftware mengapa Anda mencobanya dan memposting temuan Anda di sini? Saya akan sangat tertarik untuk melihat apakah ada perbedaan yang mencolok. Sejujurnya, saya akan cukup terkejut jika salah satu dari ini berdampak.

1) Manfaat dari instantiasi sebelumnya, yang merupakan biaya tetap satu kali selama masa pakai fungsi tampaknya benar-benar minimal dan jauh melampaui ambang batas yang dapat diukur.

2) Saya tidak dapat berbicara tentang ini karena saya tidak melakukannya. Namun, jika penangan Anda adalah fungsi lambda yang berbeda, maka mereka tidak berbagi apa-apa sejak awal karena semuanya berjalan dalam proses/wadah terpisah menurut pemahaman saya.

3) Sama.