> On 2 Nov 2022, at 09:11, Christian Lindig <christian.lin...@citrix.com> wrote: > > > >> On 1 Nov 2022, at 17:59, Edwin Török <edvin.to...@citrix.com> wrote: >> >> >> Edwin Török (2): >> xenctrl.ml: make domain_getinfolist tail recursive >> xenctrl: use larger chunksize in domain_getinfolist >> >> tools/ocaml/libs/xc/xenctrl.ml | 25 ++++++++++++++++++------- >> 1 file changed, 18 insertions(+), 7 deletions(-) > > Acked-by: Christian Lindig <christian.lin...@citrix.com> > > >> It was calling the Xen domainfolist hypercall N/2 times. >> Optimize this such that it is called at most 2 times during normal use. >> >> Implement a tail recursive `rev_concat` equivalent to `concat |> rev`, >> and use it instead of calling `@` multiple times. > > Are there any assurances about the order in elements returned by > domain_getinfolist? I understand that the change maintains the current > behaviour but are we even required to maintain that order? Because otherwise > we could return the reverse list and save more work.
Maintaining the current (reversed) order in the C stubs is useful to be able to extract the largest domid so we know where to continue. However we don't necessarily have to maintain the order on the higher level function available in the .mli, it just happens that `rev_concat` gives us the results in the order that we want. Although perhaps using an array rather a list here might be better, and we could move resizing/reallocing that array into the C stub, and have just a nicer (and perhaps faster) interface in the C/OCaml API, by producing less garbage than lists (a single Array.t allocation rather than N list elements). (Although I don't usually like pushing complexity like that into C stubs, for now I'm happy with the performance of the code as is). There are more issues in these C stubs in xenctrl, I'll be pouring over the code and try to send a few more patches. Best regards, --Edwin
