ScratchABit generally works well for typical "embedded" size of projects, on the order of 1MB of raw code. It's also written in a way "aware" of potential bottlenecks, e.g. common operations, like browsing around and DB saving are optimized, operation which are known to be "not instant", e.g. complete disassembly write-out or full-text search, have progress indicators.
However, would be useful to perform more dedicated load testing on bigger files. Following areas can be identified:
- Opening of structure executable/object formats (currently ELF is supported). For example, parsing ELF files with big string tables may take noticeable time (handled by 3rd-part lib). E.g., would be nice to test performance of loading tens-of-MB ELF files.
- Testing saving of projects with 8MB or more of raw binary code.
- Like above, but disassembly writing/full-text search.
ScratchABit generally works well for typical "embedded" size of projects, on the order of 1MB of raw code. It's also written in a way "aware" of potential bottlenecks, e.g. common operations, like browsing around and DB saving are optimized, operation which are known to be "not instant", e.g. complete disassembly write-out or full-text search, have progress indicators.
However, would be useful to perform more dedicated load testing on bigger files. Following areas can be identified: