[R] Remove stringi dependency

[vspinu]

I am building a predictor for amazon lambda where the hard limit of all unpacked dependencies is 250MB. The xgboost + deps is already 92MB mostly due to the 56MB of stringi.

I have looked at the code-base briefly and all of the use-cases of stringi seem to be easily replaceable by base R functionally.

Would you be ok with that? I can have a look into a PR.

[trivialfis]

Sure. But are you compiling everything from source? If so, did you strip out the debug symbols in stringi and xgboost?

[trivialfis]

I noticed that for CPU only build, with gcc-9, the shared object in XGBoost is only 5.5MB without debug symbol:

cmake -DCMAKE_BUILD_TYPE=Release -DUSE_OPENMP=ON

[vspinu]

I am installing from CRAN archive. This is how it looks:

g++ -std=gnu++11 -I"/home/vspinu/bin/R-4.0.0-bin/include" -DNDEBUG -I./include -I./dmlc-core/include -I./rabit/include -I. -DXGBOOST_STRICT_R_MODE=1 -DDMLC_LOG_BEFORE_THROW=0 -DDMLC_ENABLE_STD_THREAD=1 -DDMLC_DISABLE_STDIN=1 -DDMLC_LOG_CUSTOMIZE=1 -DXGBOOST_CUSTOMIZE_LOGGER=1 -DRABIT_CUSTOMIZE_MSG_ -DRABIT_STRICT_CXX98_  -I/usr/local/include  -fopenmp -DDMLC_CMAKE_LITTLE_ENDIAN=1 -pthread -fpic  -g -O2  -c xgboost_R.cc -o xgboost_R.o
g++ -std=gnu++11 -I"/home/vspinu/bin/R-4.0.0-bin/include" -DNDEBUG -I./include -I./dmlc-core/include -I./rabit/include -I. -DXGBOOST_STRICT_R_MODE=1 -DDMLC_LOG_BEFORE_THROW=0 -DDMLC_ENABLE_STD_THREAD=1 -DDMLC_DISABLE_STDIN=1 -DDMLC_LOG_CUSTOMIZE=1 -DXGBOOST_CUSTOMIZE_LOGGER=1 -DRABIT_CUSTOMIZE_MSG_ -DRABIT_STRICT_CXX98_  -I/usr/local/include  -fopenmp -DDMLC_CMAKE_LITTLE_ENDIAN=1 -pthread -fpic  -g -O2  -c xgboost_custom.cc -o xgboost_custom.o
gcc -I"/home/vspinu/bin/R-4.0.0-bin/include" -DNDEBUG -I./include -I./dmlc-core/include -I./rabit/include -I. -DXGBOOST_STRICT_R_MODE=1 -DDMLC_LOG_BEFORE_THROW=0 -DDMLC_ENABLE_STD_THREAD=1 -DDMLC_DISABLE_STDIN=1 -DDMLC_LOG_CUSTOMIZE=1 -DXGBOOST_CUSTOMIZE_LOGGER=1 -DRABIT_CUSTOMIZE_MSG_ -DRABIT_STRICT_CXX98_  -I/usr/local/include   -fpic  -g -O2  -c xgboost_assert.c -o xgboost_assert.o
gcc -I"/home/vspinu/bin/R-4.0.0-bin/include" -DNDEBUG -I./include -I./dmlc-core/include -I./rabit/include -I. -DXGBOOST_STRICT_R_MODE=1 -DDMLC_LOG_BEFORE_THROW=0 -DDMLC_ENABLE_STD_THREAD=1 -DDMLC_DISABLE_STDIN=1 -DDMLC_LOG_CUSTOMIZE=1 -DXGBOOST_CUSTOMIZE_LOGGER=1 -DRABIT_CUSTOMIZE_MSG_ -DRABIT_STRICT_CXX98_  -I/usr/local/include   -fpic  -g -O2  -c init.c -o init.o
g++ -std=gnu++11 -I"/home/vspinu/bin/R-4.0.0-bin/include" -DNDEBUG -I./include -I./dmlc-core/include -I./rabit/include -I. -DXGBOOST_STRICT_R_MODE=1 -DDMLC_LOG_BEFORE_THROW=0 -DDMLC_ENABLE_STD_THREAD=1 -DDMLC_DISABLE_STDIN=1 -DDMLC_LOG_CUSTOMIZE=1 -DXGBOOST_CUSTOMIZE_LOGGER=1 -DRABIT_CUSTOMIZE_MSG_ -DRABIT_STRICT_CXX98_  -I/usr/local/include  -fopenmp -DDMLC_CMAKE_LITTLE_ENDIAN=1 -pthread -fpic  -g -O2  -c amalgamation/xgboost-all0.cc -o amalgamation/xgboost-all0.o
In file included from ./dmlc-core/include/dmlc/././json.h:33:0,
                 from ./dmlc-core/include/dmlc/./parameter.h:26,
                 from ./dmlc-core/include/dmlc/registry.h:14,
                 from amalgamation/../src/metric/metric.cc:6,
                 from amalgamation/xgboost-all0.cc:13:

NDEBUG is there, should it be something else? I guess it's so big because of the inclusion of rabbit and dmlc, no?

In any case I am completely fine with 30MB object for xgboost. The real issue is stringi which is not a hard dependency; just used for plots and tree parser.

[trivialfis]

It's the -g flag, which generates debug symbols.

[vspinu]

Thanks for this. I halved the size of the deployment by compiling with -g0 O3. Could reduce stringi size to 33MB this way.

[trivialfis]

Awesome! Now do you think it's worthy to remove stringi?

[trivialfis]

Although for XGBoost I highly recommend using CMake to build instead of changing flags yourself.

[vspinu]

I would still say it's worth to remove stringi. It's used for non-critical stuff and it's a low hanging fruit anyhow. 33MB it's not a big deal for sure, but given that the entire R runtime with 23 packages on board is only 49MB it surely feels disproportionate.

I highly recommend using CMake to build instead of changing flags yourself.

It's not an option for us. We are using renv (pyenv counterpart for R) to snapshot the entire project. So dealing with custom installation would be a major complication.

[trivialfis]

@vspinu Sure, PR is welcomed. ;-)

[trivialfis]

@vspinu Not rushing into anything, any update?

[vspinu]

Not yet. Busy month at work. Added to my reminders. Will provide a PR within a week or two. Thanks for pinging.

[trivialfis]

No problem. Just following up. Have fun with it.