🔵 عنوان مقاله
How Slow is Channel-Based Iteration?
🟢 خلاصه مقاله:
این مقاله پرسش «تکرار مبتنی بر channel در Go چقدر کند است؟» را با یک مثال عملی بررسی میکند. تیم Dolt سه الگو را مقایسه کرده است: دو رویکرد مبتنی بر channel و یک روش iterator کشیدنی با iter.Pull. نتیجه کلی این است که هرچند channelها برای همزمانی، مدیریت فشار برگشتی و جداسازی تولیدکننده/مصرفکننده عالیاند، اما در حلقههای محاسباتیِ حساس به کارایی، سربار همگامسازی، زمانبندی goroutine و تخصیصها محسوس میشود. در مقابل، iter.Pull (و حلقههای ساده روی دادههای خطی) معمولاً سبکتر و بهینهترند. توصیه نهایی: وقتی به همزمانی واقعی نیاز دارید از channel استفاده کنید؛ برای مسیرهای داغ که فقط پیمایش میخواهند، سراغ iterator کشیدنی یا حلقههای ساده بروید.
#Go #Golang #Channels #Iteration #Performance #Benchmarking #Concurrency #Dolt
🟣لینک مقاله:
https://golangweekly.com/link/175626/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
How Slow is Channel-Based Iteration?
🟢 خلاصه مقاله:
این مقاله پرسش «تکرار مبتنی بر channel در Go چقدر کند است؟» را با یک مثال عملی بررسی میکند. تیم Dolt سه الگو را مقایسه کرده است: دو رویکرد مبتنی بر channel و یک روش iterator کشیدنی با iter.Pull. نتیجه کلی این است که هرچند channelها برای همزمانی، مدیریت فشار برگشتی و جداسازی تولیدکننده/مصرفکننده عالیاند، اما در حلقههای محاسباتیِ حساس به کارایی، سربار همگامسازی، زمانبندی goroutine و تخصیصها محسوس میشود. در مقابل، iter.Pull (و حلقههای ساده روی دادههای خطی) معمولاً سبکتر و بهینهترند. توصیه نهایی: وقتی به همزمانی واقعی نیاز دارید از channel استفاده کنید؛ برای مسیرهای داغ که فقط پیمایش میخواهند، سراغ iterator کشیدنی یا حلقههای ساده بروید.
#Go #Golang #Channels #Iteration #Performance #Benchmarking #Concurrency #Dolt
🟣لینک مقاله:
https://golangweekly.com/link/175626/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Dolthub
How slow is channel-based iteration?
We benchmarked channel-based iterators v. those provided by the iter package and share the results.
❤1👍1🔥1
🔵 عنوان مقاله
The Speed of Random Number Generators
🟢 خلاصه مقاله:
در این مقاله، Daniel سرعت گزینههای رایج تولید اعداد تصادفی در Go را مقایسه میکند. او نشان میدهد که math/rand/v2 با الگوریتم PCG در سناریوهای غیرامنیتی سریعترین گزینه است و از نسخه قدیمیتر math/rand عملکرد بهتری دارد، در حالی که crypto/rand بهدلیل تمرکز بر امنیت بهطور قابلتوجهی کندتر است. جمعبندی عملی: برای کارهای غیررمزنگاری که سرعت و قابلیت بازتولید مهماند، از math/rand/v2 (PCG) استفاده کنید؛ اما برای مقاصد امنیتی، با وجود هزینهی عملکرد، crypto/rand انتخاب درست است.
#Go #Golang #RandomNumberGeneration #Performance #Benchmark #PCG #mathrand #cryptorand
🟣لینک مقاله:
https://golangweekly.com/link/175977/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
The Speed of Random Number Generators
🟢 خلاصه مقاله:
در این مقاله، Daniel سرعت گزینههای رایج تولید اعداد تصادفی در Go را مقایسه میکند. او نشان میدهد که math/rand/v2 با الگوریتم PCG در سناریوهای غیرامنیتی سریعترین گزینه است و از نسخه قدیمیتر math/rand عملکرد بهتری دارد، در حالی که crypto/rand بهدلیل تمرکز بر امنیت بهطور قابلتوجهی کندتر است. جمعبندی عملی: برای کارهای غیررمزنگاری که سرعت و قابلیت بازتولید مهماند، از math/rand/v2 (PCG) استفاده کنید؛ اما برای مقاصد امنیتی، با وجود هزینهی عملکرد، crypto/rand انتخاب درست است.
#Go #Golang #RandomNumberGeneration #Performance #Benchmark #PCG #mathrand #cryptorand
🟣لینک مقاله:
https://golangweekly.com/link/175977/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Daniel Lemire's blog
Speed of random number generators in Go
We often need to generate random numbers in software. We need them for games, simulations, testing, and so forth. In many of these cases, we would like to use the fastest generator we can find, as long as it is reasonably random-looking. In some instances…
👍1
Forwarded from Linux Labdon
🔵 عنوان مقاله
Ubuntu 25.10's Rust Coreutils Transition Has Uncovered Performance Shortcomings
🟢 خلاصه مقاله:
Ubuntu 25.10 در حال جایگزینی Rustا Coreutils بهجای GNU Coreutils است. آزمایشهای اولیه نشان میدهد نسخه Rust در برخی سناریوها کندتر از پیادهسازی C در GNU Coreutils عمل میکند. با این حال هنوز تا انتشار پایدار چند هفته باقی مانده و توسعهدهندگان upstream در حال بهینهسازی و رفع شکافهای کارایی هستند تا ضمن بهرهمندی از مزایای ایمنی Rust، به کارایی همتراز برسند.
#Ubuntu2510 #Ubuntu #RustCoreutils #GNUCoreutils #Linux #Performance #OpenSource #RustLang
🟣لینک مقاله:
https://www.phoronix.com/news/Ubuntu-Rust-Coreutils-Perf
➖➖➖➖➖➖➖➖
👑 @Linux_Labdon
Ubuntu 25.10's Rust Coreutils Transition Has Uncovered Performance Shortcomings
🟢 خلاصه مقاله:
Ubuntu 25.10 در حال جایگزینی Rustا Coreutils بهجای GNU Coreutils است. آزمایشهای اولیه نشان میدهد نسخه Rust در برخی سناریوها کندتر از پیادهسازی C در GNU Coreutils عمل میکند. با این حال هنوز تا انتشار پایدار چند هفته باقی مانده و توسعهدهندگان upstream در حال بهینهسازی و رفع شکافهای کارایی هستند تا ضمن بهرهمندی از مزایای ایمنی Rust، به کارایی همتراز برسند.
#Ubuntu2510 #Ubuntu #RustCoreutils #GNUCoreutils #Linux #Performance #OpenSource #RustLang
🟣لینک مقاله:
https://www.phoronix.com/news/Ubuntu-Rust-Coreutils-Perf
➖➖➖➖➖➖➖➖
👑 @Linux_Labdon
Phoronix
Ubuntu 25.10's Rust Coreutils Transition Has Uncovered Performance Shortcomings
Ubuntu 25.10's transition to using Rust Coreutils in place of GNU Coreutils has uncovered a few performance issues so far with the Rust version being slower than the C-based GNU Coreutils
❤1
🔵 عنوان مقاله
From 19 Hours to Under a Second: Building a Blazing-Fast TCP Scanner in Go
🟢 خلاصه مقاله:
با یک روایت عملی، مقاله توضیح میدهد چگونه یک اسکنر ساده TCP که ۱۹ ساعت طول میکشید، با بازطراحی در Go به ابزاری «زیر یک ثانیه» تبدیل شد. ابتدا نشان میدهد چرا اسکن مبتنیبر net.Dial حتی با همزمانی محدود گرفتار زمانهای انتظار، محدودیت FD و سربار syscall میشود. سپس با گذار از اتصالهای کامل به اسکن SYN، ساخت بستهها، فیلترکردن پاسخها با BPF، و نگهداری وضعیت سبکوزن، سربار کرنل و زمانبندی به شدت کاهش مییابد. بهینهسازیهایی مانند batch کردن ارسال/دریافت، پیشاختصاص بافرها، کاهش تخصیصها با sync.Pool، و حلقههای رویدادی کارا (epoll/kqueue) همراه با تنظیمات سیستم (ulimit، بافرهای سوکتی و sysctl) throughput را به حداکثر میرساند. با پروفایلکردن مداوم (pprof) و راستیآزمایی با ابزاری مانند Nmap، هم دقت و هم کارایی تضمین میشود. خروجی نهایی: الگوی عملی برای ساخت ابزارهای پرسرعت شبکه در Go—ترکیبی از انتخاب مدل درست (SYN بهجای connect)، کاهش سربارها، batch کردن، اندازهگیری پیوسته، و پایبندی به اصول ایمنی و اخلاق اسکن. این مطلب در Golang Weekly برجسته شده است.
#Go #Golang #TCP #PortScanning #Networking #Performance #Concurrency #SystemsProgramming
🟣لینک مقاله:
https://golangweekly.com/link/176335/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
From 19 Hours to Under a Second: Building a Blazing-Fast TCP Scanner in Go
🟢 خلاصه مقاله:
با یک روایت عملی، مقاله توضیح میدهد چگونه یک اسکنر ساده TCP که ۱۹ ساعت طول میکشید، با بازطراحی در Go به ابزاری «زیر یک ثانیه» تبدیل شد. ابتدا نشان میدهد چرا اسکن مبتنیبر net.Dial حتی با همزمانی محدود گرفتار زمانهای انتظار، محدودیت FD و سربار syscall میشود. سپس با گذار از اتصالهای کامل به اسکن SYN، ساخت بستهها، فیلترکردن پاسخها با BPF، و نگهداری وضعیت سبکوزن، سربار کرنل و زمانبندی به شدت کاهش مییابد. بهینهسازیهایی مانند batch کردن ارسال/دریافت، پیشاختصاص بافرها، کاهش تخصیصها با sync.Pool، و حلقههای رویدادی کارا (epoll/kqueue) همراه با تنظیمات سیستم (ulimit، بافرهای سوکتی و sysctl) throughput را به حداکثر میرساند. با پروفایلکردن مداوم (pprof) و راستیآزمایی با ابزاری مانند Nmap، هم دقت و هم کارایی تضمین میشود. خروجی نهایی: الگوی عملی برای ساخت ابزارهای پرسرعت شبکه در Go—ترکیبی از انتخاب مدل درست (SYN بهجای connect)، کاهش سربارها، batch کردن، اندازهگیری پیوسته، و پایبندی به اصول ایمنی و اخلاق اسکن. این مطلب در Golang Weekly برجسته شده است.
#Go #Golang #TCP #PortScanning #Networking #Performance #Concurrency #SystemsProgramming
🟣لینک مقاله:
https://golangweekly.com/link/176335/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
docs.serviceradar.cloud
From 19 Hours to Under a Second: Building a Blazing-Fast TCP Scanner in Go | ServiceRadar
How ServiceRadar turned a 19-hour TCP discovery job into a sub-second SYN scan by leaning on raw sockets, BPF, and Go assembly.
🔵 عنوان مقاله
Go's Green Tea Garbage Collector
🟢 خلاصه مقاله:
** در Go 1.25 یک garbage collector آزمایشی به نام Green Tea معرفی شده که با هدف کاهش تأخیر و نوسان، بهبود کارایی و مصرف حافظه، و مقیاسپذیری بهتر ارائه میشود. این قابلیت فعلاً بهصورت opt-in و از طریق فلگهای مستند در release notes فعال میشود و پیشفرض نیست. نتایج اولیه بسته به بار کاری میتواند متفاوت باشد؛ در صورت پسرفت میتوان به GC فعلی بازگشت. تیم Go با تکیه بر بازخورد و سنجش میدانی، در نسخههای بعدی آن را بهبود میدهد و در صورت موفقیت، میتواند بر راهبرد آینده GC در Go اثر بگذارد.
#Go #Golang #GreenTea #GarbageCollection #Go125 #MemoryManagement #Performance #Runtime
🟣لینک مقاله:
https://golangweekly.com/link/176318/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Go's Green Tea Garbage Collector
🟢 خلاصه مقاله:
** در Go 1.25 یک garbage collector آزمایشی به نام Green Tea معرفی شده که با هدف کاهش تأخیر و نوسان، بهبود کارایی و مصرف حافظه، و مقیاسپذیری بهتر ارائه میشود. این قابلیت فعلاً بهصورت opt-in و از طریق فلگهای مستند در release notes فعال میشود و پیشفرض نیست. نتایج اولیه بسته به بار کاری میتواند متفاوت باشد؛ در صورت پسرفت میتوان به GC فعلی بازگشت. تیم Go با تکیه بر بازخورد و سنجش میدانی، در نسخههای بعدی آن را بهبود میدهد و در صورت موفقیت، میتواند بر راهبرد آینده GC در Go اثر بگذارد.
#Go #Golang #GreenTea #GarbageCollection #Go125 #MemoryManagement #Performance #Runtime
🟣لینک مقاله:
https://golangweekly.com/link/176318/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
go.dev
The Green Tea Garbage Collector - The Go Programming Language
Go 1.25 includes a new experimental garbage collector, Green Tea.
🔵 عنوان مقاله
How We Saved 70% CPU and 60% Memory in Refinery’s Go Code
🟢 خلاصه مقاله:
**تیم Refinery روی یک سرویس مهم مبتنی بر Go با مصرف بالای CPU و Memory کار میکرد و با پروفایلینگ دقیق (pprof، tracing و بنچمارکهای انتهابهانتها) گلوگاههای واقعی را پیدا کرد. بیشترین صرفهجویی با حذف کارهای غیرضروری بهدست آمد: حذف پردازشها و serialization تکراری، دوری از reflection در مسیرهای داغ، جایگزینی JSON در hot path با دسترسی مستقیم/کدگذاری ساده، پیشاختصاص slices/maps و بازاستفاده از بافرها برای کاهش allocation و فشار GC. در همروندی، بهجای goroutineهای بدونمهار، از worker poolهای محدود و backpressure استفاده شد، کارها batch و دادهها تا حد امکان stream شدند تا قفلزنی و جابهجایی زمینه کاهش یابد. همچنین چند حلقه O(n^2) با ایندکسگذاری مبتنی بر map/set جایگزین شد، نتایج گران با cache کردن تکرار نشد و الگوهای I/O با خواندن/نوشتن تجمیعی بهینه شدند. در نهایت با تکیه بر allocationهای روی stack، استفاده از sync.Pool و روشهای zero-copy، نیاز به GC پایین آمد. نتیجه: حدود 70% کاهش مصرف CPU و 60% کاهش Memory همراه با بهبود تاخیرهای p95/p99. درس کلیدی: بهینهسازی اغلب یعنی کمتر کار کردن—اندازهگیری کن، کار زائد را حذف کن و سادهسازی را تکرار کن.
#Go #Golang #Performance #Profiling #CPU #Memory #Optimization #pprof
🟣لینک مقاله:
https://golangweekly.com/link/176624/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
How We Saved 70% CPU and 60% Memory in Refinery’s Go Code
🟢 خلاصه مقاله:
**تیم Refinery روی یک سرویس مهم مبتنی بر Go با مصرف بالای CPU و Memory کار میکرد و با پروفایلینگ دقیق (pprof، tracing و بنچمارکهای انتهابهانتها) گلوگاههای واقعی را پیدا کرد. بیشترین صرفهجویی با حذف کارهای غیرضروری بهدست آمد: حذف پردازشها و serialization تکراری، دوری از reflection در مسیرهای داغ، جایگزینی JSON در hot path با دسترسی مستقیم/کدگذاری ساده، پیشاختصاص slices/maps و بازاستفاده از بافرها برای کاهش allocation و فشار GC. در همروندی، بهجای goroutineهای بدونمهار، از worker poolهای محدود و backpressure استفاده شد، کارها batch و دادهها تا حد امکان stream شدند تا قفلزنی و جابهجایی زمینه کاهش یابد. همچنین چند حلقه O(n^2) با ایندکسگذاری مبتنی بر map/set جایگزین شد، نتایج گران با cache کردن تکرار نشد و الگوهای I/O با خواندن/نوشتن تجمیعی بهینه شدند. در نهایت با تکیه بر allocationهای روی stack، استفاده از sync.Pool و روشهای zero-copy، نیاز به GC پایین آمد. نتیجه: حدود 70% کاهش مصرف CPU و 60% کاهش Memory همراه با بهبود تاخیرهای p95/p99. درس کلیدی: بهینهسازی اغلب یعنی کمتر کار کردن—اندازهگیری کن، کار زائد را حذف کن و سادهسازی را تکرار کن.
#Go #Golang #Performance #Profiling #CPU #Memory #Optimization #pprof
🟣لینک مقاله:
https://golangweekly.com/link/176624/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Honeycomb
How We Saved 70% of CPU and 60% of Memory in Refinery’s Go Code, No Rust Required.
We've just released Refinery 3. 0 , a performance-focused update which significantly improves Refinery's CPU and memory efficiency.
👍2❤1
🔵 عنوان مقاله
A look into how JavaScript source maps work
🟢 خلاصه مقاله:
خلاصهای از ساختوکار source map در JavaScript: کدی که در مرورگر اجرا میشود معمولاً پس از transpile، bundle و minify با کد اصلی تفاوت دارد. source map پلی است میان این دو تا بتوانید در DevTools مثل کد اصلی breakpoint بگذارید و خطاها را بخوانید. یک source map فایل JSONی است با فیلدهایی مثل version، file، sources، names، sourcesContent و یک رشته mappings که با Base64 VLQ فشرده شده و با بخشهای دلتایی موقعیتهای کد تولیدشده را به سطر/ستونهای فایلهای اصلی (و در صورت وجود، نامها) نگاشت میکند. ابزارهایی مثل TypeScript و Babel نگاشت را هنگام تبدیل میسازند، Webpack/Rollup/esbuild آنها را ترکیب میکنند و Terser در مرحله minify این زنجیره را حفظ میکند؛ این همان chain شدن source map است. مرورگر از طریق دستور sourceMappingURL (فایل خارجی یا data URI) map را میخواند و با رعایت CORS آن را decode کرده و در DevTools نمایش و دیباگ را بر اساس کد اصلی ممکن میسازد؛ همچنین پلتفرمهایی مثل Sentry با دریافت map میتوانند stack traceهای production را de-minify کنند. در عمل، به خاطر اندازه و حریم خصوصی، بهتر است در production از الگوهایی چون hidden-source-map یا nosources-source-map، میزبانی امن، و فشردهسازی/کش استفاده کنید. محدودیتها شامل دقت ستونی ناقص در برخی تبدیلها، کدهای dynamic/eval، ناسازگاری مسیرها و سوگیریهای نگاشت است. بهترین رویهها: فعالسازی map در تمام مراحل build، اعتبارسنجی در DevTools، اطمینان از CORS مناسب برای ابزار خطا، کنترل نسخه ابزارها و آزمون remap شدن خطاها در CI.
#JavaScript #SourceMaps #WebDev #Debugging #DevTools #Bundlers #Performance
🟣لینک مقاله:
https://golangweekly.com/link/176649/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
A look into how JavaScript source maps work
🟢 خلاصه مقاله:
خلاصهای از ساختوکار source map در JavaScript: کدی که در مرورگر اجرا میشود معمولاً پس از transpile، bundle و minify با کد اصلی تفاوت دارد. source map پلی است میان این دو تا بتوانید در DevTools مثل کد اصلی breakpoint بگذارید و خطاها را بخوانید. یک source map فایل JSONی است با فیلدهایی مثل version، file، sources، names، sourcesContent و یک رشته mappings که با Base64 VLQ فشرده شده و با بخشهای دلتایی موقعیتهای کد تولیدشده را به سطر/ستونهای فایلهای اصلی (و در صورت وجود، نامها) نگاشت میکند. ابزارهایی مثل TypeScript و Babel نگاشت را هنگام تبدیل میسازند، Webpack/Rollup/esbuild آنها را ترکیب میکنند و Terser در مرحله minify این زنجیره را حفظ میکند؛ این همان chain شدن source map است. مرورگر از طریق دستور sourceMappingURL (فایل خارجی یا data URI) map را میخواند و با رعایت CORS آن را decode کرده و در DevTools نمایش و دیباگ را بر اساس کد اصلی ممکن میسازد؛ همچنین پلتفرمهایی مثل Sentry با دریافت map میتوانند stack traceهای production را de-minify کنند. در عمل، به خاطر اندازه و حریم خصوصی، بهتر است در production از الگوهایی چون hidden-source-map یا nosources-source-map، میزبانی امن، و فشردهسازی/کش استفاده کنید. محدودیتها شامل دقت ستونی ناقص در برخی تبدیلها، کدهای dynamic/eval، ناسازگاری مسیرها و سوگیریهای نگاشت است. بهترین رویهها: فعالسازی map در تمام مراحل build، اعتبارسنجی در DevTools، اطمینان از CORS مناسب برای ابزار خطا، کنترل نسخه ابزارها و آزمون remap شدن خطاها در CI.
#JavaScript #SourceMaps #WebDev #Debugging #DevTools #Bundlers #Performance
🟣لینک مقاله:
https://golangweekly.com/link/176649/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Do more with less. | Polar Signals
The Inner Workings of JavaScript Source Maps
A deep dive into how JavaScript source maps work under the hood, with examples showing how all the pieces fit together.
👍1
🔵 عنوان مقاله
some odd discrepancies when profiling their Go code on macOS.
🟢 خلاصه مقاله:
این مطلب در Golang Weekly به این میپردازد که چرا هنگام پروفایل کردن برنامههای Go روی macOS گاهی نتایج ناسازگار و غافلگیرکننده دیده میشود؛ پروفایلها بین اجراها تغییر میکنند و معمولاً با اعداد بهدستآمده روی Linux یا در CI همخوان نیستند. ریشه مسئله بیشتر به تفاوت ابزارها، رفتار سیستمعامل و ویژگیهای بار کاری برمیگردد: نمونهبرداری pprof ممکن است نقاط داغ کوتاهعمر را نبیند، مدیریت توان و زمانبندی macOS بر نرخ نمونهگیری و زمان اجرای رشتهها اثر میگذارد، و حضور cgo یا کتابخانههای بومی میتواند ردگیری پشته و نمادگذاری را دشوار کند. توصیهها شامل ترکیب pprof با Instruments، اجرای طولانیتر برای پایداری نمونهگیری، کنترل نویز محیطی (مثل ثابت نگهداشتن GOMAXPROCS و اجرای سیستم در شرایط کمبار)، تکرار چندباره اندازهگیری و نهایتاً مقایسه با مقادیری است که روی Linux (در صورت استقرار نهایی) بهدست میآیند. جمعبندی این است که پروفایلهای macOS را راهنمایی جهتدار بدانید و تصمیمهای نهایی کارایی را بر اساس پلتفرم مقصد اتخاذ کنید.
#Go #Golang #macOS #Profiling #Performance #pprof #Instruments #AppleSilicon
🟣لینک مقاله:
https://golangweekly.com/link/176897/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
some odd discrepancies when profiling their Go code on macOS.
🟢 خلاصه مقاله:
این مطلب در Golang Weekly به این میپردازد که چرا هنگام پروفایل کردن برنامههای Go روی macOS گاهی نتایج ناسازگار و غافلگیرکننده دیده میشود؛ پروفایلها بین اجراها تغییر میکنند و معمولاً با اعداد بهدستآمده روی Linux یا در CI همخوان نیستند. ریشه مسئله بیشتر به تفاوت ابزارها، رفتار سیستمعامل و ویژگیهای بار کاری برمیگردد: نمونهبرداری pprof ممکن است نقاط داغ کوتاهعمر را نبیند، مدیریت توان و زمانبندی macOS بر نرخ نمونهگیری و زمان اجرای رشتهها اثر میگذارد، و حضور cgo یا کتابخانههای بومی میتواند ردگیری پشته و نمادگذاری را دشوار کند. توصیهها شامل ترکیب pprof با Instruments، اجرای طولانیتر برای پایداری نمونهگیری، کنترل نویز محیطی (مثل ثابت نگهداشتن GOMAXPROCS و اجرای سیستم در شرایط کمبار)، تکرار چندباره اندازهگیری و نهایتاً مقایسه با مقادیری است که روی Linux (در صورت استقرار نهایی) بهدست میآیند. جمعبندی این است که پروفایلهای macOS را راهنمایی جهتدار بدانید و تصمیمهای نهایی کارایی را بر اساس پلتفرم مقصد اتخاذ کنید.
#Go #Golang #macOS #Profiling #Performance #pprof #Instruments #AppleSilicon
🟣لینک مقاله:
https://golangweekly.com/link/176897/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Dolthub
Go CPU Profiling on MacOS is Broken
Profiling on MacOS gives unexpected and misleading results.
🔵 عنوان مقاله
What is sync.Pool and How to Use It Properly
🟢 خلاصه مقاله:
این مطلب دو بخش کلیدی از دنیای Go را پوشش میدهد: نخست، sync.Pool بهعنوان سازوکاری برای استفاده مجدد از اشیای موقت با هدف کاهش allocation و فشار بر GC. استفاده درست از آن یعنی: فقط برای اشیای کوتاهعمر و بدون مالکیت منابع خارجی، تعریف New برای ساخت در صورت خالی بودن، مقداردهی/Reset قبل از Put، و عدم اتکا به ماندگاری یا اندازه Pool. نتیجهگیری مهم: sync.Pool جایگزین cache پایدار نیست و باید با بنچمارکگیری مزیتش را سنجید. دوم، مقاله Jesús Espino در Devtrovert درباره Scanner در کامپایلر Go توضیح میدهد که چگونه متن کد را به token تبدیل میکند، شناسهها، لیترالها و عملگرها را میشناسد، با فاصلهها و کامنتها و خطاها برخورد میکند و خروجی را به parser میسپارد. ترکیب این دو دیدگاه، هم به بهینهسازی عملکرد برنامهها کمک میکند و هم درک عمیقتری از فرایند پردازش کد در Go میدهد.
#Go #Golang #syncPool #Compiler #Scanner #Performance #Concurrency #MemoryManagement
🟣لینک مقاله:
https://golangweekly.com/link/176904/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
What is sync.Pool and How to Use It Properly
🟢 خلاصه مقاله:
این مطلب دو بخش کلیدی از دنیای Go را پوشش میدهد: نخست، sync.Pool بهعنوان سازوکاری برای استفاده مجدد از اشیای موقت با هدف کاهش allocation و فشار بر GC. استفاده درست از آن یعنی: فقط برای اشیای کوتاهعمر و بدون مالکیت منابع خارجی، تعریف New برای ساخت در صورت خالی بودن، مقداردهی/Reset قبل از Put، و عدم اتکا به ماندگاری یا اندازه Pool. نتیجهگیری مهم: sync.Pool جایگزین cache پایدار نیست و باید با بنچمارکگیری مزیتش را سنجید. دوم، مقاله Jesús Espino در Devtrovert درباره Scanner در کامپایلر Go توضیح میدهد که چگونه متن کد را به token تبدیل میکند، شناسهها، لیترالها و عملگرها را میشناسد، با فاصلهها و کامنتها و خطاها برخورد میکند و خروجی را به parser میسپارد. ترکیب این دو دیدگاه، هم به بهینهسازی عملکرد برنامهها کمک میکند و هم درک عمیقتری از فرایند پردازش کد در Go میدهد.
#Go #Golang #syncPool #Compiler #Scanner #Performance #Concurrency #MemoryManagement
🟣لینک مقاله:
https://golangweekly.com/link/176904/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
YouTube
What Is sync.Pool in Go & How to Use It Properly
We'll not only talk about what sync.Pool is, but also look into how empty interfaces and slices behave under the hood, so we can understand how to use sync.Pool correctly in real situations.
Keep in mind this video is for learning purposes, so NOT every…
Keep in mind this video is for learning purposes, so NOT every…
🔵 عنوان مقاله
Go's Runtime May Someday Start Explicitly Freeing Some Internal Memory?
🟢 خلاصه مقاله:
** Chris Siebenmann به ایدهای اشاره میکند که هنوز توسعه نیافته است: احتمال اینکه Go Runtime در آینده بتواند بخشی از حافظه داخلی خودش را بهصورت صریح به سیستمعامل برگرداند. هدف، کاهش RSS و رفتار بهتر زیر فشار حافظه—بهویژه در سرویسهای طولانیمدت و محیطهای کانتینری—است، اما با ریسک افت کارایی بهخاطر افزایش syscallها، page faultها و از دست رفتن cacheها. هنوز جزئیات و زمانبندی روشن نیست و اگر هم پیش برود، احتمالاً بهصورت آزمایشی و opt-in ارائه میشود. در صورت پیادهسازی در نسخههای بعدی Go، این تغییر میتواند شیوههای مرسوم تنظیم حافظه در تولید را تحت تأثیر قرار دهد.
#Go #Golang #Runtime #MemoryManagement #GarbageCollection #Performance #Containers #Cloud
🟣لینک مقاله:
https://golangweekly.com/link/176902/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Go's Runtime May Someday Start Explicitly Freeing Some Internal Memory?
🟢 خلاصه مقاله:
** Chris Siebenmann به ایدهای اشاره میکند که هنوز توسعه نیافته است: احتمال اینکه Go Runtime در آینده بتواند بخشی از حافظه داخلی خودش را بهصورت صریح به سیستمعامل برگرداند. هدف، کاهش RSS و رفتار بهتر زیر فشار حافظه—بهویژه در سرویسهای طولانیمدت و محیطهای کانتینری—است، اما با ریسک افت کارایی بهخاطر افزایش syscallها، page faultها و از دست رفتن cacheها. هنوز جزئیات و زمانبندی روشن نیست و اگر هم پیش برود، احتمالاً بهصورت آزمایشی و opt-in ارائه میشود. در صورت پیادهسازی در نسخههای بعدی Go، این تغییر میتواند شیوههای مرسوم تنظیم حافظه در تولید را تحت تأثیر قرار دهد.
#Go #Golang #Runtime #MemoryManagement #GarbageCollection #Performance #Containers #Cloud
🟣لینک مقاله:
https://golangweekly.com/link/176902/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
🔵 عنوان مقاله
Red, Green, Refactor: Writing Perfect Go, with TDD
🟢 خلاصه مقاله:
** این مطلب سه دیدگاه مکمل برای بهبود کدنویسی در Go ارائه میکند: بهکارگیری چرخه Red–Green–Refactor در TDD برای ساخت پکیجهای کوچک و APIهای شفاف و ریفکتور امن با تکیه بر تستهای سریع؛ مرور کاربردی John Arundel از sync.Pool برای کاهش فشار تخصیص در مسیرهای داغ، با تأکید بر اینکه این سازوکار «کش» نیست و اقلام آن ممکن است هر لحظه حذف شوند، و استفاده از آن فقط با اندازهگیری و پروفایل توجیهپذیر است؛ و توضیح Jesús Espino در Devtrovert درباره Scanner در کامپایلر Go و نحوه تبدیل کد منبع به توکنها، که منشأ برخی خطاها و رفتار ابزارها را روشن میکند. جمعبندی: با TDD کیفیت و قابلیت نگهداری را بالا ببرید، sync.Pool را صرفاً وقتی به کار بگیرید که دادهها گلوگاه تخصیص را نشان میدهند، و با شناخت روند اسکن، ابزار بهتر و کد خواناتر بسازید.
#Go #Golang #TDD #syncPool #Refactoring #GoCompiler #Performance #Profiling
🟣لینک مقاله:
https://golangweekly.com/link/176903/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Red, Green, Refactor: Writing Perfect Go, with TDD
🟢 خلاصه مقاله:
** این مطلب سه دیدگاه مکمل برای بهبود کدنویسی در Go ارائه میکند: بهکارگیری چرخه Red–Green–Refactor در TDD برای ساخت پکیجهای کوچک و APIهای شفاف و ریفکتور امن با تکیه بر تستهای سریع؛ مرور کاربردی John Arundel از sync.Pool برای کاهش فشار تخصیص در مسیرهای داغ، با تأکید بر اینکه این سازوکار «کش» نیست و اقلام آن ممکن است هر لحظه حذف شوند، و استفاده از آن فقط با اندازهگیری و پروفایل توجیهپذیر است؛ و توضیح Jesús Espino در Devtrovert درباره Scanner در کامپایلر Go و نحوه تبدیل کد منبع به توکنها، که منشأ برخی خطاها و رفتار ابزارها را روشن میکند. جمعبندی: با TDD کیفیت و قابلیت نگهداری را بالا ببرید، sync.Pool را صرفاً وقتی به کار بگیرید که دادهها گلوگاه تخصیص را نشان میدهند، و با شناخت روند اسکن، ابزار بهتر و کد خواناتر بسازید.
#Go #Golang #TDD #syncPool #Refactoring #GoCompiler #Performance #Profiling
🟣لینک مقاله:
https://golangweekly.com/link/176903/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Bitfield Consulting
Red, green, refactor: writing perfect Go, with TDD — Bitfield Consulting
Make it work, then make it right: the “red, green, refactor” technique helps us craft Go code that’s correct and beautiful. It’s easy! Shall we play a game?