Jump to content

Notestē man programmiņu

camel

By camel,
in Programmēšana

 Share

Recommended Posts

camel

camel

Posted
Posted (edited)

Taisot mazu c# programmiņu, pamanīju ka PictureBox ar Stretch vai Zoom scaling izzīmējas uzkrītoši leni. Rokot tālāk pamanīju, ka problēma ir tikai, ja programmu kompilē priekš x64, priekš x86 kompilētais variants ir 7 reizes atrāks.


Lai izslēgtu iespēja, ka problēma ir ar manu pc/windows konfigurāciju, būtu jauki, ja vēl kāds to notestētu.


Pielikumā ir c# VS projektiņs ar kompilētiem .exe priekš x86 un x64. Exe failus var atrast zem \TestPictureBoxSpeedA\bin\x64\Debug\net8.0-windows un \TestPictureBoxSpeedA\bin\x86\Debug\net8.0-windows.

Jāpalaiž abi exe un jāpiefiksē vidējais (average) izzīmēšanas laiks.

 

TestPictureBoxSpeedA.zip

 

Papildus gan vispirms ir jāinstalē .NET Runtime 8
priekš x86:

https://dotnet.microsoft.com/en-us/download/dotnet/thank-you/runtime-desktop-8.0.21-windows-x86-installer


priekš x64:

https://dotnet.microsoft.com/en-us/download/dotnet/thank-you/runtime-desktop-8.0.21-windows-x64-installer

 

Edited by camel
Link to comment
Share on other sites
camel

camel

Posted
  • Author
Posted (edited)

ok..., testētājus te neatradīs, varbūt šī Minesweepera programmīņa kādam noderēs:
Minesweeper.zip

 

atšķirībā no klasiskā minesweepera te laukaumu var pastaipīt lielāku un ķeksīši reģistrējas, kad peles taustiņš tiek nospiests nevis tad kad atlaists.
 

minesweeper.jpg.4a22bb91024491bf93bf93d870c35d88.jpg

Edited by camel
Link to comment
Share on other sites
HIGH-Zen

HIGH-Zen

Posted
Posted (edited)

Nav vairs hackers.lv, cietnis.lv laiki, tagad programmēšana un datori praktiski nevienam neinteresē. Šodienas publika var 24h nonstop muldēt par sadzīvi tādās tēmās, kā "Par dzīvi Latvijā, par šo forumu, un kaut ko no tā..... .". Pēc 2h tavs topiks hotlistā jau aizbraucis prom un to neviens neredz, ja speciāli neskatās "Nelasīts saturs" sadaļu. Un arī šajā sadaļā tēma ilgi nenoturēsies.

Vēl pirms 10 gadiem tā nebija, bet nu daudz ūdeņu ir aiztecējuši kopš tā. Visiem ir p0huj.

Pārbaudīts šajā vecajā tēmā:

 

Personīgi es notestēju tikai x64, jo uz mana datora bija vajadzīgais .NET runtaime x64, bet x86 slinkums čakarēties un kačāt, jo tā uz mana datora nav.

Kā arī neesmu Minesweepera fans. Plus ķeksīši reģistrējas, kad peles taustiņš reģistrējas, kad peles taustiņš tiek nospiests, nevis tad, kad atlaists, kā visās normālās programmās.

 

Novēlu tev veiksmi!

Edited by HIGH-Zen
Link to comment
Share on other sites
AndrisBB

AndrisBB

Posted
Posted
pirms 20 stundām , camel teica:

Lai izslēgtu iespēja, ka problēma ir ar manu pc/windows konfigurāciju, būtu jauki, ja vēl kāds to notestētu.

 

Nav vēlmes čakarēties Windows, bet nu problēma tak esot atrisināta iekš KB5045935.

https://developercommunity.microsoft.com/t/pictureboxBackgroundImage-take-long-tim/10777811

 

 

Link to comment
Share on other sites
  • 3 weeks later...
AlCohol

AlCohol

Posted
Posted
pirms 7 stundām , camel teica:

Ar chatgpt palīdzību sāku lipināt mazu razor pages projektiņu - web lapu ar balsošanu par dažādām tēmām.

Saturs ir pārsvarā chatgpt ģenerēts, noteikti saturīgāks kā būtu paša rakstīts.

 

Nāc notestē: https://nobalso.zbks.eu

 

Aktuāls balsojums par Trampu:
https://nobalso.zbks.eu/Category/243

bez AI varēji to monotoņu lapu ar <td> sarakstīt. ietaupītu tos 25eur mēnesī. 

Link to comment
Share on other sites
HIGH-Zen

HIGH-Zen

Posted
Posted

Windows 11 Pro 25H2 palaižot viņš neko nedara, bet uzreiz iziet. Es jau nobijos, ka šifrētājvīrusu esmu saķēris riskējot bez virtuālās mašīnas, bet virustotal nomierināja. Kārtējā .NET freimvorka figņa, kas nedarbojas uz Win 11. Uz Win 10 kaut kādas šausmīgas pīkstoņas pavadībā parādās vairāki tab-i ar kaut kādiem grafikiem. Izcils kalkulators :) 

Link to comment
Share on other sites
  • 1 month later...
camel

camel

Posted
  • Author
Posted

Turpinot šo (bezjēdzīgo) tēmu ...

 

Sākotnēji taisot nobalso.zbks.eu lapu ar c# Asp.Net pamaniju, ka šī app palaista uz linux aizņem diezgan daudz ram - pēc startēšanas kādus 160mb un tad aizņemtais ram apjoms pakapēniski palielinās līdz kādiem 300mb, kad lapa tiek klikšķināta. Uz lokāla datora tāds ram patēriņš protams nav problēma, bet manai oracle cloud always free instancei ir tikai 1gb ram...

 

Meklējot ekonomiskāku risinājumu, secināju ka laiks mācīties go lang. Palasiju go dokumentāciju, tutoriāļus un pateicoties tam ka go mēģina nekomplicēt koda rakstīšanu (un chatgpt), man ir izdevies nobalso lapu pārrakstīt go. Kompilēta app aizņem ap 25mb uz diska un ap 20mb ram - problēma trisināta. Turklāt go un templ koda rakstīšana ar VS Code ir gana ērta.

 

Ja kādam interesē, kods te:

https://github.com/Camel-RD/nobalso.go

Link to comment
Share on other sites
AndrisBB

AndrisBB

Posted
Posted (edited)

Lai tev te nav garlaicīgi vienam pašam.

 

Pašlaik strādāju pie sīkas programmiņas ar ko kontrolēt pāris PTZ kameras. Konkrēti pašlaik pie paša 'virtuālā joystika'. Ļoti tālu līdz kautkam lietojamam.

Pa lielam C++ Qt applikācija.

 

Screenshot-2026-01-17-at-16-08-01.png

Kontrolēt kameras kā šīs

https://pro.sony/en_GB/products/ptz-network-cameras

https://proav.co.uk/cameras-lenses/canon-cr-n700-4k-ptz-camera-black

 

Edited by AndrisBB
Link to comment
Share on other sites
  • 1 month later...
camel

camel

Posted
  • Author
Posted

Gribēju noskaidrotu kapēc man C:\ diskā brīvās vietas paliek mazāk, kad nekas netiek instalēts. Sagūglēt risinājumu nemācēju, gāju taisīt savu. Tagad ir tapusi .Net aplikācija, kas izmanto Winstāstitat.exe lai nolasītu diska failu sistēmu uz .csv failu. Nolasīto .csv failu var salīdzināt ar vecāku, lai atrastu kurā mapē vai failā ir aizņemtās vietas pieaugums.

 

lejuplādēt var te:

https://github.com/Camel-RD/Camel-RD.github.io/releases/download/2020.09-1/DriveSizeChangeExplorer.zip

(tur klāt būs arī Winstāstitat.exe un programmas kods)

 

tas izskatās šādi:

DriveSizeChangeExplorer.jpg.037708ec147ffafddf1708a81a324e1b.jpg

 

  • Patīk 3
Link to comment
Share on other sites
  • 2 months later...
AndrisBB

AndrisBB

Posted
Posted

Neviens izskatās neko interesantu vairs neprogrammē 💻

 

Paturpinot tēmu par Filu sistēmām.

Klasiskā problēma - ja ir kautkāds videoreģitrātors, videokamera, action kamera utt, kas nepārtraukti ieraksta un 'rotē' failus, tad ļoti ātri SD karte vai disks kļūst fragmentēts, it īpaši ja izmanto FAT/exFAT.

(Tāpat kā senajos laikos ar Windows diskiem, kad bij de-fragmentācijas tūlis ik pa laikam jāpalaiž).

 

Ar disku parasto jau problēmas jau nav īpaši lielas. Bet SD kartes gadījumā tas ir dienzan sāpīgi.

Pieņemsim ka ir SD karte kura mierīgi darbojas ar 30MB/s un ierakstītāmais video ir teiksim 10MB/s.

Viss darbojas lieliski ar svaigu, tiko noformatētu SD karti.

 

Tiklīdz sākas fragmentācija, tā arī uzrodas problēmas faktiski 2 apstākļu pēc:

 

1: SD kartes parasti lasa/raksta 1 - 4MB blokos. Ja FAT clustera izmērs ir 32kb un tas ir izmētāts pa visu karti, tad nākas nolasīt/ierakstīr visus 4MB, lai tikai ierakstītu 32kb.

Attiecīgi atkarībā no fragmentācijas pakāpes 30MB/s vars no nespēj un mistiski pazūd ierakstāmais materiāls.

 

2. Tākā SD kartes raksta/lasa 1 vai 4MB blakus un kamera raksta random 32kb, tad kartei nākas:

- nolasīt 4MB

- modificēt to 4MB bloku atmiņā ar jaunajiem 32kb (neaiztiekot to kas nav jāizdzēš)

- Izdzēst tos 4MB uz kartes

- Ierakstīt jaunos modificētos 4MB

 

Attiecīgi lai ierakstītu 32kb, nākas izdzēst 4MB. Kāds rezultāts? SD karte tiek nolietota 100 reizes ātrāk kā tās paredzamais mūžš. Kas parasti notiek ar lētāk ķīniešu kamerām.

 

Interesantā daļa - izdomāt FAT Linux/RTOS driveri/stratēģiju kas vienmēr raksta bezfragmentu blokos.

 

Aiz neko darīt sāku veidot tūli, kas visualizē clasterus un ģenerē histogrammu ar skaitļiem, cik fragmentēti ir faili.

Piemēram uz kartes ir 311 faili ar 4 fragmentiem un 360 faili ar 30 fragmentiem.

 

Screenshot-2026-05-04-at-15-02-58.png

 

 

 

 

 

 

 

 

 

 

 

 

  • Patīk 2
Link to comment
Share on other sites
AndrisBB

AndrisBB

Posted
Posted

Iepriekšējais skrīnšots no faktiski dārgākā videoreģistrātora, kas nopērkams.

(diezgan slikti)

 

Salīdzinājumam DJI action kamera pamanās ierakstīt visus failus perfektos blokos. Katrs fails - viens garš fragments.

 

Screenshot-2026-05-04-at-15-41-51.png 

  • Patīk 1
Link to comment
Share on other sites
aoma

aoma

Posted
Posted

Vajadzētu man te kaut ko ierakstīt, lai foruma biedri trīs dienas pērtos kā mušas pa tūtu, bet es no šitā neko nesaprotu, pieļauju, ka pārējie arī. Piedod, Andri :D 

Link to comment
Share on other sites
AndrisBB

AndrisBB

Posted
Posted (edited)

Ko tur saprast vai nesaprast? 

 

Teiksim ja tu paņem SD karti un noformatē kā FAT vai exFAT, vai jebkuru citu no tās famīlijas (nekādas būtiskas atšķirības starp variācijām nav).

Failu sistēma sadalīs to SD karti 'virtuālos' klāsteros, tipiski izmēros no 32kb līdz 128kb, kā nu kurai OS labāk patīk.

FAT princīpā ir ļoti primitīva failu sistēma, kur SD kartes (vai jebkura cita diska) sākumā viņa rezervēs pāris megabaitus 'Failu Tabulas' vajadzībām (atkarībā no diska/klasteru izmēra).

Failu tabulā katram failam vienkārši būs atzīmēts pirmais klāsters, kur tas fails sākas. Tas vienkārši ir LinkedList (programētāji sapratīs) ar klasteru adresēm. Tapēc arī ļoti vienkārši var atjaunot itkā izdzēstus failus. Seko tikai klāsteru ķēdītei un pārkopē.

 

Problēma tāda ka nepārtraukti dzēšot tie klāsteri vairs nav pēc kārtas, jo pa vidam bij kāds cits fails, kur pirmstam izdzēsts.

Nu tas tākā jebkuram kas atcerās Windows defragmentācijas tūļa laikus vajadzētu būt skaidram. Kā tas redzms tam 86MB failam. Fails sadalīts 30 fragmentos, citi mazliet lielāki, citi mazāki. 

 

Principā jau tas nekādā veidā neietekmē ikdienas lietošanu.

Bet ja tā teiksim ir videokamera, kas izmanto SD kartes ātrumu pilnībā, tad pēc laika rodas problēma.

- Jo vairāk tie fragmenti izkliedētāki un jo vairāk to fragmentu, jo vairāk IO operācijas. Attiecīgi kamera vairs nespēj ierakstīt vajadzīgo apjomu.

- Jo vairāk tie fragmenti izkliedētāki un jo vairāk to fragmentu, jo vairāk izdēs/ieraksti cikli. SD karte nevar ierakstīt teiksim 1kb. Atkarībā no izmēra tie ir 1 - 4MB. Tātad katru reizi kad vajag ierakstīt to nelielo pāris klāsteru fragmentu, nākas idzēst 4MB bloku un pārrakstīt pa jaunam. Attiecīgi SD karte nolietojas ļoti ātri.

 

Tapēc arī itkā pat industriālas SD kartes ļoti ātri nobeidzas dažādos videoreģistrātoros, pat pašos dārgākajos.

 

Tai problēmai nevajadzētu būt problēmai, ja FAT drivers ir optimizēts konkrētajai vajadzībai, kā tas ir DJI gadījumā, kur viens fails ir viens garš fragments.

 

Tūlis vienkārši palīdz ātri vizualizēt fragmentācijas pakāpi. Tīri debuggošanai. 

 

Edited by AndrisBB
Link to comment
Share on other sites
aoma

aoma

Posted
Posted
Pirms 3 minūtēm , AndrisBB teica:

Tīri debuggošanai

Brrr. Tīri aiz neko darīt.

Link to comment
Share on other sites
AndrisBB

AndrisBB

Posted
Posted (edited)

Protams ne aiz neko darīt.

Bet lai salīdzinātu cik labi ar problēmu tiek galā dažādi daškamu (aka videoreģistrātoru) ražotāji 😂

Edited by AndrisBB
Link to comment
Share on other sites
TOoMoOT

TOoMoOT

Posted
Posted

Vai DJI action kamerai ir bijuši tikpat sarežģīti apstākļi ar ierakstīto/dzēsto video skaitu un izmēriem kā pirmajam piemēram?

Link to comment
Share on other sites
AndrisBB

AndrisBB

Posted
Posted

Plus/mīnus. (pa lielam tas pats ar lielākām kartēm vai mazākiem failiem)

 

DJI acīmredzot izmanto mazliet citu stratēģiju.

Sadala SD kartes vietu 'slotos' (teiksim tajos 1.6GB uz failu), un vienmēr raksta katru jaunu failu no slota sākuma un tādā veidā rotē.

 

Pirmā izmanto standarta stratēģiju, kur atrod pirmo brīvo vietu (kautvai vienu klāsteri) un raksta tur, kad aizpilda, meklē nākamo.

  • Patīk 1
Link to comment
Share on other sites
AndrisBB

AndrisBB

Posted
Posted (edited)

Vispār jau lielākā interese ir kādam ir jābūt fragmentācijas līmenim, lai tas kautkādā veidā sāktu ietekmēt SD kartes teorētisko caurlaidību.

 

Tipiski lai rakstītu tos pašus 90MB/s izmantojos SD kartes CMD25 komandu (Multi-Block Write):

Ja fails ir vienā nepārtauktā blokā, tad visa rakstīšana pa lielam ir ar vienu komandu.

  

Host                                SD Card
  |                                    |
  |── CMD25 (start address) ──────────>|
  |<─ R1 response ────────────────────|
  |                                    |
  |── [Data Block 0] ────────────────>|
  |── [Data Block 1] ────────────────>|  ← continuous stream
  |── [Data Block 2] ────────────────>|
  |── [Data Block N] ────────────────>|
  |── CMD12 (stop) ──────────────────>|  ← or predefined count
  |<─ R1b (busy until flushed) ───────|

 

Bet ja ir ntie fragmenti: 

Host                                    SD Card
  |                                        |
  |  === Fragment 1: addr 0x001000 ===     |
  |                                        |
  |── CMD25 (addr=0x001000) ─────────────>|
  |<─ R1 (ready) ────────────────────────|
  |── [Data Block 0] ───────────────────>|
  |── [Data Block 1] ───────────────────>|
  |── CMD12 (stop) ─────────────────────>|
  |<─ R1b (busy ~200µs) ────────────────|  ← card flushes write buffer
  |                                        |
  |  === Fragment 2: addr 0x036A00 ===     |  ← address jumps, new fragment
  |                                        |
  |── CMD25 (addr=0x036A00) ────────────>|
  |<─ R1 (ready) ────────────────────────|
  |── [Data Block 0] ───────────────────>|
  |── [Data Block 1] ───────────────────>|
  |── [Data Block 2] ───────────────────>|
  |── CMD12 (stop) ─────────────────────>|
  |<─ R1b (busy ~350µs) ────────────────|  ← card flushes write buffer
  |                                        |
  |  === Fragment 3: addr 0x1C2000 ===     |  ← address jumps again
  |                                        |
  |── CMD25 (addr=0x1C2000) ────────────>|
  |<─ R1 (ready) ────────────────────────|
  |── [Data Block 0] ───────────────────>|
  |── [Data Block 1] ───────────────────>|
  |── [Data Block 2] ───────────────────>|
  |── [Data Block 3] ───────────────────>|
  |── CMD12 (stop) ─────────────────────>|
  |<─ R1b (busy ~200µs) ────────────────|  ← done
  |                                        |

 

(nu tas viss teorētiski)

 

Edited by AndrisBB
Link to comment
Share on other sites
Racer

Racer

Posted
Posted

Man ir pāris ķīniešu novērošanas kameras, kas raksta SD kartē, kad ir kustība, patiesībā laikam raksta visu laiku un saglabā, kad ir kustība, jo ierakstā ir kāda sekunde pirms objekta parādīšanās kadrā. Tad gan jau fragmentējas utt. Režīms ir kad karte pilna - raksta pa virsu. Kādu 5 gadu laikā bija pāris reizes, kad paziņoja, ka karte kirdik. Vienu izvilku un uztaisīju nevis quick, bet full format Win vidē un joprojām strādā, otra izbeidzās, nomainīju. Varbūt tas ir saistīts ar Andra teikto.

Link to comment
Share on other sites
ggg97

ggg97

Posted
Posted

Neesmu kursā, bet laikam tāpēc dažu iekārtu OS, piemēram NAS, izmanto tehnoloģiju, kad  cache sīkfaili tiek uzkrāti RAMā līdz noteiktam apjomam un tad grūsti uz OS SDkarti. Šī tehnoloģija, iespējams, nederēs visos scenārijos.

Pirms 1 minūtes , Racer teica:

Režīms ir kad karte pilna - raksta pa virsu. Kādu 5 gadu laikā

Man ar vienā vecā lētā ipkamerā ~5gadi, un SD lasās. nekādi paziņojumi nav bijuši.

Link to comment
Share on other sites
AndrisBB

AndrisBB

Posted
Posted (edited)
1 stundu atpakaļ, Racer teica:

Varbūt tas ir saistīts ar Andra teikto.

Nu tur iespējams kombinācija, jo SD kartes jau ar dažādas, ar dažādiem NAND moduļiem -> SLC, MLC utt, kur pārrakstāmo ciklu skaits var būt no 3 000 - 100 000 (atkarībā no tipa). Bet nu tas neatceļ faktu, ka neatkarīgi no tipa optimizēta rakstīšana cikla/riņkveida ierakstam var paildzināt kartes mūžu desmitiem reižu.

 

1 stundu atpakaļ, ggg97 teica:

Man ar vienā vecā lētā ipkamerā ~5gadi, un SD lasās. nekādi paziņojumi nav bijuši.

Viss jau atkarīgs cik intensīvi raksta. Ja kautkāds videoreģistrātors ar 3 kamerām (uz priekšu, kabīne un aizmugure) un teiksim katrs 4K video ar kautkādiem 10MB/s, tad jau pa pāris stundām pārraksta pat 1TB karti. Ja tas reģistrātors tiek izmantots kautkāda komercauto, kas brauc 8+ stundas dienā, tad kartei kirdik pa pāris mēnešiem vai pat ātrāk.

A kautkāda 50+ MB/s ātruma karte tagad vismaz 200+ eiriki gabalā.

 

Nu ja raksta tik uz kustību, 1080p ar relatīvi zemu bitreitu, tad jau iet gadiem.

 

1 stundu atpakaļ, ggg97 teica:

sīkfaili tiek uzkrāti RAMā līdz noteiktam apjomam un tad grūsti uz OS SDkarti. Šī tehnoloģija, iespējams, nederēs visos scenārijos.

Teorētiski jau der, bet ne videoreģistrātoram, kam kurš var tikt atslēgts izslēdzot aizdedzi vai kautkādas avārijas gadījumā. Nepaspēji ierakstīt SD kartē, video kukūu.

 

 

 

 

 

  

Edited by AndrisBB
Link to comment
Share on other sites
Boņs

Boņs

Posted
Posted
pirms 21 stundām , AndrisBB teica:

Teorētiski jau der, bet ne videoreģistrātoram, kam kurš var tikt atslēgts izslēdzot aizdedzi vai kautkādas avārijas gadījumā. Nepaspēji ierakstīt SD kartē, video kukūu. 

Nav tik traki, videoreģistratoriem jau izsenis lika nelielu aķi, pēc tam pārgāja uz palielu kondensatoru, lai izvairītos no šiem riskiem.

 

Link to comment
Share on other sites
AndrisBB

AndrisBB

Posted
Posted

Mazliet pačakarējos un tagad varu uzģenerēt pilnībā fragmentētu FAT/exFAT file sistēmu. Teiksim 3 klasteri izmantoti, 3 brīvi.

 

Būs jāsaģenerē vairākas SD kartes ar teiksim:

- 1 brīvs, 1 izmantots klasters

- 16 brīvi, 21 izmantots klasters

- ......

- Pilnībā tukša failu sistēma

 

Tad uz kameras pameģināt pārkopēt 10 x 200MB failus un paskatīties kāds ātrums.

Tad varēs redzēt vai fragmentācija kautko būtiski ietekmē vai kā ar to tiek galā dažādas kameras.

 

Screenshot-2026-05-07-at-22-00-36.png

Screenshot-2026-05-07-at-22-01-48.png

 

 

 

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share
Go to topic listing
×
×
  • Create New...