Lines Matching full:merge
29 * Given several files containing CTF data, merge and uniquify that data into
35 * be involved in a single merge at any given time, so the process decreases in
37 * consolidated, finally resulting in a single merge of two large CTF graphs.
38 * Unfortunately, the last merge is also the slowest, as the two graphs being
44 * is due to an observation that the merge time increases at least quadratically
50 * That is, a merge should produce the same output every time, given the same
52 * ordering on the merge process, thus ensuring that a given set of input files
62 * merge batches of files in a predictable order. Files are read by the main
149 * kernel). We perform a merge between the tdata_t for this module and the
159 * the existing data, we can perform what is known as an additive merge. In
339 * We're going to continually merge the first two entries on the queue, in init_phase_two()
340 * placing the result on the end, until there's nothing left to merge. in init_phase_two()
429 /* merge it into the right slot */ in worker_runphase1()
582 * to happen again, but links are generally fast, and we can't allow the merge
813 /* Additive merge with data from `withfile' */ in main()
902 /* Prepare for the merge */ in main()
908 * Start the merge in main()
915 warning("No ctf sections found to merge\n"); in main()
936 * additive merge, we need a type tree that has been uniquified in main()