.. vim: noexpandtab fileencoding=utf-8 nomodified wrap textwidth=270 foldmethod=marker foldmarker={{{,}}} foldcolumn=4 ruler showcmd lcs=tab\:|- list tabstop=8 noexpandtab nosmarttab softtabstop=0 shiftwidth=0
:date: 2024.01.09 20:04:48
:_modified: 1970.01.01 00:00:00
:tags: SW,Arduino
:authors: Gilhad
:summary: SpeedTestPgm_v.0.1
:title: SpeedTestPgm_v.0.1
:nice_title: |logo| %title% |logo|
%HEADER%
SpeedTestPgm_v.0.1
--------------------------------------------------------------------------------
Tl;dr; - Jak je rychlá práce s řetězci v paměti, versus v PROGMEM (F-makro)? - Mě to vyšlo celkem nastejno, kdo chce, může si to překontrolovat či upravit po svém.
Brzdit by se to nijak výrazně nemělo, co jsem koukal do poznámek v knihovnách Arduina, tak PROGMEM (a F-makro) se od normální verze liší naprosto nepatrně.
Ale šedivá je teorie, zelený strom života, tak jsem si zkusil udělat testy na Arduino Mega (protože to používáš ty) a vyšlo mi, že je to v podstatě stejné, ale co zdržuje jsou výpisy přez Serial.
Příklad jsem se pokusil udělat tak, aby do toho nemohl překladač moc optimalizovat (proto ty volatile, jinak to normálně sečetl a vložil rovnou výsledek) a PROGMEM musí být const, nebo mimo funkci ``__
Protože vypisovat stovky řetězců je otročina, napsal jsem si program v Pythonu na napsání programu v ino.
Zracovávají se unikátní řetězce o délce 8 znaků, v páru testů se ličí jen pořadím znaků na 5. a 6. místě, 7. a 8. místo je pořadí řetězce, aby to kompilátor prostě nemohl zoptimalizovat.
Takže tady jsou výsledky a zdrojáky ``__
.. code::
Sketch uses 57658 bytes (22%) of program storage space. Maximum is 253952 bytes.
Global variables use 2146 bytes (26%) of dynamic memory, leaving 6046 bytes for local variables. Maximum is 8192 bytes.
...
Test_Pgm_Print: 6800
Test_Raw_Print: 6801
Test_Pgm_Cnt: 102
Test_Raw_Cnt: 87
Je vidět, že u tisku je to jedno, u přímé práce je to o 17% pomalejší, což by většinou vadit nemělo.