[SERVER-2180] Make tools use shared library Created: 06/Dec/10 Updated: 23/Jun/15 Resolved: 23/Jun/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Build |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Tim Niemueller | Assignee: | Unassigned |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
linux x86_64 |
||
| Issue Links: |
|
||||||||
| Participants: | |||||||||
| Description |
|
Currently tools like mongodump link all required objects into the binary. The commonFiles variable in SConstruct demonstrates this. It would be much more efficient if the tools would link against the shared mongoclient library (which also includes commonFiles). Especially on a loaded system where many of those tools (and other client applications) run at the same time this can considerably lower the memory footprint and improve cache performance. It would also improve MongoDB's conformance with packaging guidelines like the one of Fedora. |
| Comments |
| Comment by Ian Whalen (Inactive) [ 23/Jun/15 ] |
|
As of the 3.0.0 release all of the mongo* tools have been rewritten in Go, and the new code can be found at https://github.com/mongodb/mongo-tools. Any future improvements or feature requests related to the rewritten tools can be filed here: https://jira.mongodb.org/browse/TOOLS. |
| Comment by Eliot Horowitz (Inactive) [ 07/Dec/10 ] |
|
using a static library will make binaries larger on some platforms, so i'd rather not do that by default. |
| Comment by Tim Niemueller [ 07/Dec/10 ] |
|
Why make it a separate ticket? So after further thinking about it I think the best solution is to use the library when linking the tools, no matter if it is the shared or the static library. If the shared library is used it improves things, if the static one is used it stays the same. Would that be a suitable change? The change is then in changing the link and target file options of the tools, rather than forcing a shared library on them. If you agree I'll fork and implement this. |
| Comment by Eliot Horowitz (Inactive) [ 07/Dec/10 ] |
|
An option might be ok. |
| Comment by Tim Niemueller [ 06/Dec/10 ] |
|
Why not make it an option in the build system? Most of the users will enjoy packages that come with the Linux system of their choice and it'll be great if MongoDB would better blend in, and support more efficient memory usage. At the same time you can keep the shared library optional as now. If it is not built, you simply link the programs against the static library, essentially resulting in similar binaries to the ones now. |
| Comment by Eliot Horowitz (Inactive) [ 06/Dec/10 ] |
|
There are 2 types of packages, official .tar.gz packages and distribution packages (rpm, etc) for .tar.gz the binaries are not put in a pre-determined place, so you can't use a .so |
| Comment by Tim Niemueller [ 06/Dec/10 ] |
|
Can you give a little detail what you mean by that? I mean virtually everything is used from shared libraries these days, certainly on Linux systems. I wouldn't mind making it this way on Linux only and keep it the way it is for other systems. Maybe if you give some info we could figure out a solution which is beneficial for everybody. Issues # |
| Comment by Eliot Horowitz (Inactive) [ 06/Dec/10 ] |
|
For some packages this might be an option, but for most systems its not feasible since shard library loading is path dependant. |