unyaffs2 slow

[GoogleCodeExporter]

When running unyaffs2 (with file filter, although this is optional) on an 
embedded/slow system the command takes a long time to complete.

A quick profile run shows that the many bsearch and qsort calls take up a lot 
of CPU. Apart from the fact that bsearch and qsort don't allow inlining the 
comparison function (like C++ equivalents allow) the size of the structures, 
with char[NAME_MAX+1] taking up most of it, probably cause a lot of useless 
copying around.

Original issue reported on code.google.com by HIGH...@gmail.com on 23 Mar 2011 at 8:09

[GoogleCodeExporter]

Dear Stijn:

Originally, these tools are designed for the modern PC to create/extract an 
yaffs2 image. I believe they may be slow on an embedded/slow system.

In the latest implement in my local trunk, the search table are replaced by a 
hash table. But for the progress bar, 2-pass algorithm are applied. A file tree 
will be built by scanning the objects header first, and objects will be 
extracted based on this file tree. Finally, files attribute will also be 
modified according to the file tree, too. So the performance may not be better 
than the yaffs2utils-0.1 implementation, and memory uses will also be 
increased. I will put the current implement into the "Download" section in the 
several days.

For the file filter option, we have to scan a file list to extract the correct 
objects to an correct file path. It will also take the long time to compare the 
objects and extract the correct file path, specially when the file list is too 
large, won't it?

After the new implementation is committed and all functionality are working 
fine, I will take times to implement a non-spooling print server based on 
RFC-1179. This is one of my objective before I jump ship (change job). So I 
will spend the less time on the enhancement of this project.

Finally, I have to say: Thanks for your help on this project. It really help me 
a lot. XD

Best Regards,
By Luen-Yung Lin

Original comment by penguin.lin on 25 Mar 2011 at 2:14

• Added labels: Performance, Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Hi Luen-Yung,

I'm looking forward to your latest implementation.
I can't really comment on the performance of it, unless I have a glimpse at the 
code.
If you can avoid a lot of copying around, as with the 0.1 version, I think you 
can save a lot of CPU cycles.

Regarding the file filter, I assume you have moved it to the second pass of the 
extraction, right?

Will you still accept patches in the future?

Regards,
Stijn

Original comment by HIGH...@gmail.com on 27 Mar 2011 at 8:58

[GoogleCodeExporter]

Hi Luen-Yung,

The latest version has significantly increased the processing speed of 
extraction.
This issue can certainly be closed.

Thanks,
Stijn

Original comment by HIGH...@gmail.com on 15 Sep 2011 at 11:24

[GoogleCodeExporter]

Dear Stijn:

Thanks for your help! :D

Original comment by penguin.lin on 16 Sep 2011 at 1:05

• Changed state: Fixed