Tim Armstrong has posted comments on this change. Change subject: IMPALA-3066: Lazy materialization of LLVM module bitcode. ......................................................................
Patch Set 1: (9 comments) http://gerrit.cloudera.org:8080/#/c/3220/1/be/src/codegen/llvm-codegen.cc File be/src/codegen/llvm-codegen.cc: Line 76: DEFINE_bool(disable_lazy_materialization, false, Is there any reason to disable it? It seems like it's strictly better so long as we have adequate test coverage. Line 97: static StringRef llvm_module_ir; It seems unnecessary to introduce more globals. Line 565: if (called_fn != NULL) MaterializeFunctionHelper(called_fn); This would blow up if it was called on a recursive function, right? THis might also do a bunch of extra work if there are multiple calls to the same function. Should we add a check for whether the function is already materialized - assuming all callees of a materialized function are materialized? Line 582: MaterializeFunction(fn); This could be skipped if we're not lazy-loading right? Or if you implemented the check described above. Line 741: MaterializeFunction(fn); This is redundant on some call paths, right? Line 785: if (!FLAGS_disable_lazy_materialization) { Consider factoring this out into its own function. FInalizeModule() is already pretty big. Line 797: nullptr NULL? Line 798: nullptr NULL? http://gerrit.cloudera.org:8080/#/c/3220/1/be/src/runtime/buffered-tuple-stream.inline.h File be/src/runtime/buffered-tuple-stream.inline.h: Line 58 This change seems reasonable, but is it related to lazy materialization? -- To view, visit http://gerrit.cloudera.org:8080/3220 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-MessageType: comment Gerrit-Change-Id: I6ed7862fc5e86005ecea83fa2ceb489e737d66b2 Gerrit-PatchSet: 1 Gerrit-Project: Impala Gerrit-Branch: cdh5-trunk Gerrit-Owner: Michael Ho <[email protected]> Gerrit-Reviewer: Michael Ho <[email protected]> Gerrit-Reviewer: Tim Armstrong <[email protected]> Gerrit-HasComments: Yes
