SpreadJS Excel yuklash unumdorligini optimallashtirish 2

- Amalga oshirish vaqtini o‘lchash orqali keraksiz ma’lumotlarni bog‘lash operatsiyalarini aniqlash va yaxshilash tajribasi -

1. Muammo holati

Loyihada React va TypeScript asosida Excel biznes ekranini amalga oshirmoqdamiz. Buning uchun SpreadJS (v17.0.1) dan foydalanib, Excel fayllarini vebda ko‘rish va tahrirlash imkoniyati yaratilgan. Tuzilma foydalanuvchi yuklagan Excel faylini shablon sifatida saqlaydi, tafsilotlar ekranida esa haqiqiy ma’lumotlarni ushbu shablonga bog‘lab, namoyish etadi.

Muammo Excel tafsilotlar ekraniga kirilganda dastlabki yuklanish vaqtining haddan tashqari uzoq bo‘lganida edi. Ekranga kirilganda Excel darhol ko‘rinmasdi. Avval bo‘sh ekran, keyin yuklanish ekrani paydo bo‘lar, shundan so‘ng yana biroz vaqt o‘tgach Excel ekrani ko‘rinardi. Ishlab chiqish muhitidagi o‘lchovlar umumiy yuklanish vaqti taxminan 25–30 soniya ekanini ko‘rsatdi. Foydalanilgan Excel fayli jami 28 ta varaqdan iborat bo‘lib, varaqlar orasidagi havolalar va formulalarni o‘z ichiga olgan nisbatan murakkab tuzilishga ega edi.

Ushbu murakkab yuklanish jarayonining qaysi qismi aslida vaqt sarflayotganini bosqichma-bosqich o‘lchash orqali muammoni topish va to‘siqni yaxshilash jarayonini ulashmoqchiman.

2. Excel fayli va satr/ustun diapazonlarini tekshirish

Dastlab Excel faylining hajmini hamda varaqlardagi satr/ustun diapazonlarini tekshirdim. Avval SpreadJS da haqiqiy ma’lumotlardan ancha katta bo‘lgan keraksiz satr/ustun diapazonlari yuklanish unumdorligiga ta’sir qilgan muammoni yaxshilagan edim. Shu sababli bu safar ham xuddi shu sabab ishtirok etayotgan bo‘lishi mumkinligini tekshirishdan boshladim.

(※ Satr/ustun diapazonlari bilan bog‘liq avvalgi unumdorlikni yaxshilash holatini https://www.nextree.io/spreadjs-egsel-roding-seongneung-coejeoghwa/ bu yerda topishingiz mumkin.)

Avvalgi holatda haqiqiy ma’lumotlar atigi taxminan 100 ta satrdan iborat bo‘lgan, biroq ichki Excel varag‘ining satr diapazoni maksimal 1 048 576 ta satrga o‘rnatilgan edi. Haqiqiy ma’lumotlardan qat’i nazar katta diapazon qayta ishlanishi kerak bo‘lgani sababli yuklanish vaqti oshgan. Keraksiz sozlangan diapazonni qisqartirish orqali unumdorlik yaxshilangan.

Bu safar ham Excel satr/ustun diapazonlarini tekshirgach, ayrim varaqlarning diapazonlari haqiqiy ma’lumotlardan ancha katta qilib o‘rnatilganini aniqladim. Loyiha Excel kiritish diapazonlaridan ko‘pi bilan 1 000 ta satr va 1 000 ta ustundan foydalanishga sozlanganligi sababli, ularni shu diapazon bilan cheklab, saqlash orqali sinov o‘tkazdim. Natijada SJS ma’lumotlari hajmi quyidagicha kamaydi.

- O‘zgartirishdan oldin: taxminan 5.35 MB (5,357,864 bayt)

- O‘zgartirishdan keyin: taxminan 4.67 MB (4,675,857 bayt) 

Biroq fayl hajmi kamayganiga qaramay, yuklanish vaqti sezilarli darajada qisqarmadi. Shuning uchun bu muammoning asosiy sababi shunchaki Excel fayli hajmi yoki satr/ustun diapazonlari emas, degan xulosaga keldim. Avval Excelning o‘zidagi keraksiz diapazonlarni qisqartirish orqali unumdorlik yaxshilangan edi. Ammo bu safar Excel yuklangandan keyin ekranda bajariladigan operatsiyalarni tekshirish zarur bo‘ldi.

3. Har bir yuklanish bosqichi uchun bajarilish vaqtini o‘lchash

Agar sabab faylning o‘zi bo‘lmasa, qaysi operatsiya haqiqatan ham vaqt sarflayotganini aniqlash kerak edi. Shu sababli Excelni ekranda ko‘rsatish jarayonini bir nechta bosqichga ajratib, bajarilish vaqtini o‘lchadim. Asosiy o‘lchov natijalari quyidagicha bo‘ldi.

Kutilganidan farqli o‘laroq, Excel faylini bevosita o‘qiydigan `workbook.open()` taxminan 2.3 soniya vaqt oldi, BindingPath ni tekshirish yoki undan keyin ma’lumotlarni qayta ishlash jarayonlari esa asosan bir necha o‘n millisekunddan oshmadi. Bunga qarama-qarshi ravishda, `setDataSource()` ni bajarish taxminan 18 soniya vaqt oldi. Bu yuklanishdagi kechikishning asosiy sababi Excel faylini o‘qish emas, balki Excel o‘qib bo‘lingandan keyin ma’lumotlarni varaqlarga bog‘lash ekanini tasdiqladi.

4. Barcha varaqlar uchun ma’lumotlarni bog‘lash jarayonini tekshirish

Sababni batafsilroq o‘rganish uchun mavjud kodni tekshirdim. Mavjud amalga oshirishda `setDataSource()` barcha varaqlar uchun bajarilardi.

const dataSource = new GC.Spread.Sheets.Bindings.CellBindingSource(data);

for (let i = 0; i < workbook.getSheetCount(); i++) {
    const sheet = workbook.getSheet(i);
    sheet.setDataSource(dataSource);
}

Ushbu Excel fayli jami 28 ta varaqdan iborat edi, biroq ulardan faqat ayrimlari haqiqatan ham ma’lumotlarni bog‘lashni talab qilardi.

Shundan so‘ng har bir varaq uchun bajarilish vaqtini o‘lchadim.

- 1-varaq: taxminan 1,021 ms

- 2-varaq: taxminan 836 ms

- 3-varaq: taxminan 805 ms

- 4-varaq: taxminan 812 ms

- 5-varaq: taxminan 783 ms

- 6-varaq: taxminan 771 ms

Bitta varaqni qayta ishlash taxminan 0.7–0.9 soniya vaqt oldi. Bundan ham muhimi, bog‘lash uchun BindingPath mavjud bo‘lmagan varaqlarda ham `setDataSource()` ni chaqirish ancha vaqt olayotgan edi. Shuning uchun muammoning asosiy sababi bog‘lashni talab qilmaydigan varaqlarda bir xil operatsiyani qayta-qayta bajarish, degan xulosaga keldim.

Biroq keyinchalik bog‘lash yo‘liga ega bo‘lmagan varaqlarda ham setDataSource() ni chaqirish nega vaqt olishini, jumladan SpreadJS ning ichki ishlashini alohida tekshirishni rejalashtirmoqdaman.

5. Ma’lumotlar bog‘lanadigan varaqlarni tanlash

Avval `setDataSource()` har bir varaq uchun bajarilardi, ammo tuzilmani o‘zgartirdim: endi faqat haqiqatan ham ma’lumotlarni bog‘lashni talab qiladigan varaqlar tanlanib, qayta ishlanadi.

const dataSource = new GC.Spread.Sheets.Bindings.CellBindingSource(data);

for (let i = 0; i < workbook.getSheetCount(); i++) {
    const sheet = workbook.getSheet(i);

    if (!sheet.visible()) {
        continue;
    }

    if (!isBindingTargetSheet(sheet)) {
        continue;
    }

    sheet.setDataSource(dataSource);
}

- Faqat boshqa varaqlar tomonidan formulalar/havolalar uchun foydalaniladigan yashirin varaqlar ham keraksiz hisob-kitoblarning oldini olish uchun ma’lumotlarni bog‘lashdan chiqarib tashlandi.

- `isBindingTargetSheet()` varaqda BindingPath mavjudligini tekshiradi. Agar hatto bitta BindingPath topilsa ham, varaq ma’lumotlarni bog‘lash maqsadi sifatida qaraladi.

Yangilangan tuzilma quyidagicha.

6. Yuklanish vaqtini yaxshilash natijalari

Mavjud amalga oshirishda test muhitida tafsilotlar ekranining umumiy yuklanish vaqti taxminan 25–30 soniyani tashkil etgan. Amalga oshirish usuli faqat ma’lumotlarni bog‘lashni talab qiladigan varaqlarni qayta ishlaydigan qilib o‘zgartirilgach, bu vaqt taxminan 15–20 soniyagacha qisqardi.

Test muhitida yuklanish vaqti taxminan 40–50% ga qisqarganini tasdiqladik. (※ Natijalar foydalanuvchining kompyuter texnik xususiyatlari, brauzer muhiti va Excel tuzilmasiga qarab farq qilishi mumkin.)

Fayl hajmini kamaytirishning o‘zi yuklanishdagi kechikishni sezilarli darajada yaxshilamagan bo‘lsa-da, yuklangandan keyin keraksiz bajarilgan vazifalar doirasini qisqartirish orqali bu ko‘rsatkichni sezilarli darajada yaxshilashga muvaffaq bo‘ldik.

7. Xulosa

Bu unumdorlikni yaxshilash holatida sabab fayl hajmi yoki Excel tuzilmasi deb taxmin qilish o‘rniga, haqiqiy yuklanish jarayonini bosqichma-bosqich o‘lchash orqali muammo tug‘dirayotgan nuqtani aniqladik.

Dastlab, avvalgi tajribamizga asoslanib, Excel’dagi qator va ustun diapazonlari sabab bo‘lishi mumkin deb taxmin qildik, biroq fayl hajmini kamaytirish yuklanish vaqtini sezilarli darajada yaxshilamadi. Shundan so‘ng yuklanish jarayonining har bir bosqichi uchun bajarilish vaqtini o‘lchadik va `setDataSource()` `workbook.open()` ga qaraganda ancha ko‘proq vaqt olayotganini aniqladik. Har bir varaqni o‘lchash orqali ushbu amal ma’lumotlarni bog‘lashni talab qilmaydigan varaqlarda ham bajarilayotganini aniqladik.

Ushbu yaxshilash natijasida test muhitida dastlabki yuklanish vaqtini taxminan 25–30 soniyadan 15–20 soniyagacha qisqartirishga muvaffaq bo‘ldik. Biroq yakuniy yuklanish vaqtini hali ham yaxshilash mumkin degan xulosaga kelganimiz sababli, optimallashtirish doirasini Excel yuklangandan keyin bajariladigan boshqa vazifalarni ham qamrab oladigan tarzda kengaytirishni rejalashtirmoqdamiz.

Murakkab Excel ekranlaridagi unumdorlik muammolarini tekshirishda nafaqat fayl hajmini hisobga olish, balki haqiqiy yuklanish jarayonida qaysi vazifalar qancha vaqt sarflashini o‘lchash va faqat zarur vazifalar bajariladigan qilib ularning doirasini qisqartirish muhim ekanini tasdiqladik.

Ma’lumotnoma hujjatlari

[SpreadJS ma’lumotlarni bog‘lash bo‘yicha rasmiy hujjatlari]

https://developer.mescius.com/spreadjs/docs/v19/features/binding

JY