Thanks again for your comments. Here is a summary of our responses since yesterday.
Garrett D'Amore wrote: > Ivek Szczesniak wrote: >> The stdio implementation in libc is among the slowest stdio >> versions out there. If you want to archive better performance you >> should use the stdio implementation in libast or use mmap(2). > This is an interesting implementation suggestion, but is outside the > scope of PSARC because it does not affect the interfaces > being proposed. We did achieve quite a speedup over the old method. > We'll take another look. > > Using libast might well incur extra PSARC oversight -- are the libast > interfaces public? Consolidation private? If they are *project > private* then you'll need to get a contract for them. Using mmap() > would be free of those issues, and is likely to be the fastest without > imposing any new interdependencies. Jonathan Adams wrote (same thread): > Without knowing about this project, yesterday I prototyped a simple change > which buffered input and output from savecore(), and it achieved a 2.5x > speedup > on an pessimal setup (/var/crash on UFS, dump device on the same disk). > > I'm codereviewing this wad, so I'll talk to the developer about this. > > I agree that this doesn't seem architectural to me. Roland Mainz wrote (same thread): > Erm... I think it shouldn't be a problem to make the |malloc()| and > <stdio> parts of libast "consolidation private" for use within OS/Net > (e.g. this are the most stable APIs of libast and very unlikely to > change) ... > > ... question is: How do I do that ? > After this, thread becomes a discussion about libasm. This project does not use libasm. Since it is still an uncommitted interface, it is unlikely that we would choose to use it right now. Brian Ruthven wrote: > Will vmdump.X be removed automatically after executing the > uncompression step? No, it is not removed. One reason is that vmdump.X files may be copied from some remote system (or accessed remotely) and then uncompressed into a temp directory. There are many different usage scenarios, and so it seems wiser to leave the choice to the user. The user can always do an "rm", with permissions. Discussed this with Brian, and he agrees that *not* automatically removing the file is the right behavior.
