By: mk 
on 17 August 2019 - 13:21
Tags:
เมื่อครั้งที่ ไมโครซอฟท์ประกาศย้ายมาใช้ Chromium แทนเอนจิน EdgeHTML เดิม ก็สัญญาว่าจะเข้าร่วมพัฒนา Chromium ด้วย และเคยเสนอแก้ปัญหา scrollbar กระตุกมาแล้ว
ล่าสุดทีมงานของไมโครซอฟท์ เสนอแพตช์ปรับปรุงการทำงานของ Chromium ให้ลดการใช้งานแบตเตอรี่ลง ในประเด็นว่า Chrome จะแคชไฟล์วิดีโอลงในดิสก์เสมอ แม้บางครั้งไม่จำเป็นต้องแคชก็ตาม ทำให้ดิสก์ทำงานตลอดเวลาและสิ้นเปลืองพลังงานโดยใช่เหตุ
แพตช์ที่ไมโครซอฟท์เสนอจึงเป็นการปิดแคชสำหรับไฟล์บางประเภท เพื่อให้อายุการใช้งานแบตเตอรี่ยาวนานขึ้น แพตช์ต้นฉบับถูกส่งเข้าโครงการ Chromium ตั้งแต่ช่วงกลางเดือน ก.ค. และได้รับเสียงตอบรับจากทีมงาน Chromium เป็นอย่างดี ตอนนี้แพตช์อยู่ในคิวเตรียม commit เรียบร้อยแล้ว
ฟีเจอร์ปิดแคชตัวนี้จะยังปิดการทำงานเป็นดีฟอลต์ใน Chrome Canary และต้องเปิดใช้เองผ่านหน้า chrome://flags
ที่มา - Chromium Gerrit, Neowin
Get latest news from Blognone
Follow @twitterapi
Comments
กลายเป็นกูเกิลมีคนช่วยแพตช์ ดีไปอีก
จะเอา Engine Chromium มาไว้ใน Edge ก็ต้องช่วยเขาหน่อยล่ะ
ผมว่าทีม dev ของ microsoft นี้เจ๋งสุดแล้ว
เจ๋งแต่พัฒนาให้คนอื่นอะนะ
ที่เขาพัฒนาเองก็ IE ไงครับ
อันนั้นคงเรียกว่า เจ๊ง 555
แต่ถ้าไม่มีก็ไว้ Load Chrome ไม่ได้นา
.net core นี่ดีมากๆเลยนะครับ
ในระบบของ Win32 MS นี่เจ๋งสุดแล้วมั้งครับ
แต่พวก internet based ก็ตรงกันข้ามเลย
Win32 เป็น API ของ MS ถ้าไม่เจ๋งสุด ก็พิกลล่ะครับ
API ออกแบบเอง กำหนดกติกาเอง ส่วนที่ Undocument ทั้งหมดก็รู้กันอยู่ภายในเอง
ส่วน Internet based นั่น Bill Gates วิสัยทัศน์ไม่ถึง กระโดดขึ้นม้าไม่ทัน ไม่ทันสร้างอิทธิพลในการกำหนดกฏเกณฑ์ชี้นำโลก (IE defacto ล้มเหลว)
ดังนั้นในส่วนที่ต้องทำตาม Standard กลางนี่สิครับที่เป็นข้อพิสูจน์ฝีมือที่แท้จริง (ในทัศนะของผม)
สำหรับ Win32 ผมไม่นับว่าเจ๋งเลย เหมือนรัฐธรรมนูญบ้านเราตอนนี้เลย เขียนเอง ชงเอง ใช้เอง มี exception ให้ตัวเองเพียบ แล้วยังมีหมกเม็ดไว้อีกซึ่งถ้าไม่มีเรื่อง ก็ไม่ค่อยมีใครอ่านทั้งหมดแล้วสังเกตุเห็นจนแดงออกมา
เป็นความเห็นจากประสบการณ์และความรู้ในการ Re-engineering มาจนพรุนครับ เจอความขี้โกงของ Win32 เยอะมากจนเขียนตำราได้เลยล่ะ
MS นี่ถนัดซ่อน Back hole เพื่อประโยชน์ของ Application ตัวเองมาตั้งแต่ MS DOS เลยครับ นี่เป็นอีกหนึ่งในหลายๆ เหตุผลหนึ่งที่ทำให้ MS DOS ไปจนถึง Windows Me มี Virus เยอะมาก เพราะช่องโหว่ที่ตั้งใจสร้างไว้มีเยอะครับ (อันนี้ผมไม่ได้โทษ Bill Gates นะครับ เขาอาจจะไม่รู้เรื่องเลยก็ได้ แต่โทษทั้งองค์กร)
พอถึงยุคเปลี่ยนมา NT Kernel แล้วต้อง Support Win32 ก็พาลทำให้ช่องโหว่ส่วนหนึ่งต้องถูกลากตามมาด้วยเพื่อความ Compatible!
ถ้าอยากรู้มากกว่านี้ด้วยตนเอง keyword คือ Wine กับ DOSBox ครับ คนที่นั่นเจอความ suck มากกว่าที่ผมเจอคนเดียว (แต่ยุค MS DOS นี่ ผมก็หนึ่งในตองอูเลยนะ)
Chrome นี่หล่ะ ตัวสูบแบต สุดๆ
browser video cache นี่แหละตัวกิน SSD write เลย
อย่างใน Firefox เปิด YouTube นี่ write byte ขนาดใหญ่กว่าขนาดไฟล์จริงของ video อีก ยกตัวอย่าง แค่ดูคลิปนี้ https://www.youtube.com/watch?v=nF3w-xnkRwE@1080p คลิปเดียว write bytes วิ่งไป 780MB เลย
เลยแก้ปัญหาด้วยการย้าย Mozilla AppData ไป HDD แล้ว junction กลับมาแทน
ใครที่ใช้ SSD แบบไม่มี DRAM cache ในตัว(อย่าง SM2263XT) นี่ระวังไว้นะครับ
Russia is just nazi who accuse the others for being nazi.
someone once said : ผมก็ด่าของผมอยู่นะ :)
? ขอบคุณที่เตือนครับ แต่คงทำอะไรไม่ได้เพราะเครื่องผมไม่มี HDD เลย มีแต่ SSD 3 ลูก - -" อย่างมากก็รอแพตช์นี้ จะไปทำ RAM Drive ก็ดูโอเวอร์ไป
ถ้าเป็น SSD มาตรฐานที่มีขนาด 1TB ขึ้นไปนี่ไม่ค่อยน่ากลัวมากเท่าไหร่ครับ ปกติในตัวจะมี DRAM มา buffer ไว้อีกทีอยู่แล้ว และระยะเวลาที่ browser buffer ก็อยู่ที่ประมาณ 15-30 วิ ซึ่งข้อมูลอาจจะถูกลบจาก DRAM buffer ก่อนเขียนลง NAND อีกที
ปัญหาคืองานส่วนมากตอนนี้การใช้ PC เป็นแบบ multitasking ซะเกือบหมด ดังนั้น DRAM อาจจะถูก read/write จากการใช้งานอื่นบีบให้รีบ flush ข้อมูลลง NAND นี่แหละครับ ดังนั้นยิ่งขนาด DRAM น้อยๆ(ที่อยู่บน SSD ขนาดน้อยๆ)ก็ยิ่งมีปัญหา
ปล. วันก่อนเช็ค Total NAND Write บน Sandisk 480GB แล้วตกใจ ขนาดไม่ค่อยได้เขียนอะไร NAND write พุ่งไป 16TB(/2 =8TB เพราะ SLC cache) ได้ไงมะรู้ครับ แต่ก็ใช้มาหลายปีแล้วหล่ะนะ
จากภาพ จะเห็นว่า DRAM บน Extreme Pro 480GB มันไม่น่าจะพอครับ โดน flush ลง NAND เกือบหมดเลย 16569/2=8284.5GB(SLC 8284.5,TLC 8284.5 วัดที่ TLC) เทียบกับ host write ที่ 8497GB แปลว่าโดน discard ขณะอยู่ที่ DRAM buffer ไปแค่ 212.5GB หรือ 2.5% เอง TT TT
Russia is just nazi who accuse the others for being nazi.
someone once said : ผมก็ด่าของผมอยู่นะ :)
ของผมมี 3 ตัวครับ
ตัวแรก Samsung 970 EVO 500GB ใช้เป็นไดรฟ์หลักมา 1 ปี (13 เดือน) เขียนไป 14.1TB ครับ แต่เปิด over provisioning ไว้ 10% ด้วย ไม่รู้จะช่วยยืดอายุได้แค่ไหน - -" (แต่อ่านแค่ 8.4TB นะ ?) เวลาใช้งาน 3,321 ชั่วโมง
ตัวสอง Sandisk Extreme Pro 480GB ใช้มา 3 ปีครึ่ง เป็นไดรฟ์หลัก 2 ปีครึ่งและเป็นไดรฟ์รอง (ใช้ sync OneDrive และลงเกมที่ไม่ใช่ OW [อันนี้อยู่ตัวแรก เอาเร็วและแรง] หรือเกมของ EA [อันนี้อยู่ตัวสุดท้าย]) เขียนไป 24.2TB ครับ (ที่เป็น Total Host Write ถ้าเป็น Total NAND Write จะเป็น 46.8TB) เวลาใช้งาน 10,994 ชั่วโมง ?
ภาพเปรียบเทียบ ของผมเรียกได้ว่าเปิดปิดรัวๆ ?
ตัวสุดท้าย ถอดมาจาก Laptop ครับ (เพราะเปลี่ยนเอา NVMe ไปใส่แทน) Toshiba KSG60ZMV256G ตัวนี้ใช้ลงเกมจาก EA (Origin) ล้วนๆ ซึ่งจริงๆ ก็แทบไม่ได้เล่น ? เขียนไปแค่ 550GB ครับ เวลาใช้งาน 2,654 ชั่วโมง จะพอๆ กับตัวแรกเพราะเอามาใส่ทีหลังไม่นาน
เขียนไปแค่ 23.4TB(24.2TB host) เองครับ ยังห่างประกัน 80 TBW อีกเยอะ ฮา
ส่วน 970 EVO ประกันที่ 300 TBW คงไม่ต้องกังวลมั้งครับ
Russia is just nazi who accuse the others for being nazi.
someone once said : ผมก็ด่าของผมอยู่นะ :)
? ก็จริงครับ จริงๆ ซื้อตัวบนๆ ก็เพื่อจะใช้แบบสบายใจนี่แหละ ตัว 970EVO นี่ว่าจะเอา over provisioning ออกเหมือนกันเพราะมันเริ่มแจ้งสีแดงแล้ว ? ของไม่จำเป็นให้ลบก็เยอะแต่ยังขี้เกียจเคลียร์
จงเป็น edge จงเป็น edge
ไหนๆ ก็เขียนกันสูบแบตฯ แล้ว เขียนกันสูบแรมให้ด้วยสิ....
แปลกใจที่ทำไมทีมงาน google ไม่รู้เรื่อง หรือแก้ไขไม่ได้
คนที่ใช้ Google Chrome Canary มันมาแล้วนะ
หัวข้อ Turn off caching of streaming media to disk.