output/binary uses inefficient logic

Bug #1313364 reported by Ben Collins
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
srecord (Ubuntu)
New
Medium
Unassigned

Bug Description

Several problems make writing output to binary extremely inefficient.

1) Each byte is written using put_char(). This method checks if !is_binary(), which in order to perform newline translations. is_binary() is always true for binary output, so it is much better to bypass put_char() and write out the entire data at once to *fp.

2) binary output checks if the output file is a regular file, and if not, does not allow seek_to() to use seek(2), but instead writes a nil to each byte up to the next record. This is completely useless on things like block devices (e.g. mtdblock for writing directly to flash). I can understand that some things, like character devices (e.g. ttySx) need this work around, but forcing it for block devices is insane. To show the issue, my flash is 128M, but only 12M is being used. The first and last byte of the flash actually have data, so this method writes a single byte at a time to the entire 128M flash (and mtdblock is already SLOW). If I disable the is_regular check, I can write my entire srecord to flash in just under 2 minutes, whereas with the original code it takes over 15 minutes.

3) The arbitrary max_data_length in record.h of 255 is weird. Due to this value, writes to binary output are forced to writing 7x255 byte data lengths and then a 7 byte data length to complete the padding. This value should be a power of 2 (256 at a MINIMUM), and it should allow for larger values in binary output, and ideally configurable. In my case, writing to mtdblock, the sector size of 0x20000 is the most efficient block size to write at a time. Being able to align writes to this block size, and write entire blocks of this size, speeds things up a bit more.

Changed in srecord (Ubuntu):
importance: Undecided → Medium
description: updated
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.