Refactor the listjobtest to allow listing of multile paths.
Review Request #126894 - Created Jan. 26, 2016 and submitted
With this change it is now possible to list multiple paths as defined via the command line. While at it, I refactored the code to clean it up: - rely on QEventLoopLocker to quit the application once all jobs have finished - use a lambda to count the listed entries - don't append to a KIO::UDSEntryList to cound the listed entries
Thanks Milian for looking at this test. I implemented it quite some time ago as a quick hack that allows to see how changes in the internal data structures of UDSEntry affect the performance and especially the memory usage of KIO::ListJob (which is what applications typically use to obtain UDSEntries). I did it in Qt4 times, when one could not use lambdas in connections. It's great to see the test simplified and extended now :-)
I have two remarks:
- Appending the listed entries to a list was intentional. If they are discarded immediately, then their memory is freed, and it is not possible to see how much memory the entries would consume in an application that lists one or more paths. I see that this original intention of the test is not obvious at all though. I should have added a comment - sorry about that!
std::cin.ignore()was also intentional. It allows to investigate the memory usage with htop, ps, or other tools while the process is still running. I know that one could also use Valgrind/Massif+massif-visualizer to get a detailed memory usage report (which also contains detailed information about where and when memory was allocated), but this has the disadvantage that the bookkeeping overhead of the memory allocator is not included (or at least it was not last time I checked). The massif method would tell you that an application that allocates 100 MiB in a single block uses more memory than an application that allocates 10 million blocks of 8 bytes each, but this is not true because some bookkeeping overhead is added to each allocation. Each allocation takes at least 32 bytes of memory when using GCC+glibc on a 64-bit system. But I guess that there must be a better way than the
cin.ignore()hack to easily get the real memory usage.