If I may ask, does anyone have any profiling information one way or the other to shed light on the situation?
On Mon, Jul 10, 2017 at 6:12 PM, R0b0t1 <r03...@gmail.com> wrote: > On Mon, Jul 10, 2017 at 6:56 PM, William L. Thomson Jr. > <wlt...@o-sinc.com> wrote: > > On Mon, 10 Jul 2017 17:47:45 -0500 > > Gordon Pettey <petteyg...@gmail.com> wrote: > > > >> On Mon, Jul 10, 2017 at 5:24 PM, Michał Górny <mgo...@gentoo.org> > >> wrote: > >> > >> > On pon, 2017-07-10 at 17:40 -0400, William L. Thomson Jr. wrote: > >> > > Stop getting lost in the weeds!!!! > >> > > You all are making this about -c vs -C. I am not talking about > >> > > that! > >> > > > >> > > LET ME CLARIFY.... > >> > > > >> > > When using -C, portage SHOULD warn for dependencies like it does > >> > > for profile and set packages, PERIOD. NOTHING to do with -c vs -C. > >> > > > >> > > When using -c the output should say in layman's terms, > >> > > "Not removing package A because it is a dependency" > >> > > >> > William, I'm not sure if you're aware of how package managers work > >> > but checking reverse dependencies of a package takes significant > >> > amount of time. > >> > >> > >> for x in $(eix -I --only-names); do time equery g $x > /dev/null; done > >> > >> The only single package on my system that took more than 2 seconds > >> total time was gcc. The idea that that is too much time to add to > >> emerge -c or -C, which in my experience already takes multiple > >> seconds to run anyway is kind of silly. > > > > IMHO anyone complaining about time taking for dependency resolution > > etc. They should spend THEIR time writing stuff in a real native > > language for speed. > > > > The difference I see with jem[1] vs java-config, is ridiculous. > > Sometimes I merge hundreds of java packages. All those milliseconds add > > up. Not to mention resources, ram, CPU, and all drains your battery... > > > > If aspects of portage were done in C or C++, or maybe even Go. There > > would be substantial performance improvements. The existing python code > > can remain. Python can load and call functions from C/C++ DSO. And vice > > versa, calling Python code from C/C++. I would say C vs C++ but that is > > up to others. > > > > https://wiki.gentoo.org/wiki/Q_applets > > What you're suggesting is actually really hard, and the root of the > problems tend to be graph traversals and path searches (for > dependencies) not so much miscellaneous milliseconds spent in > interpreter overhead. > > Then again, I suppose there will be people on computers slow enough > where the latter does make a difference. > > > Put my time where my mouth is... Well I did, its called jem. What is > > jem? Its java-config ported to C. I would be looking to port more of > > Gentoo's tools to C for longevity and speed. Not speed of development, > > but speed for everyone else. Instead I am doing C for other projects. > > > > 1. https://github.com/Obsidian-StudiosInc/jem > > > > P.S. > > jem does need a bit more work to replace java-config entirely. Its > > designed to not be Gentoo specific. There is little interest from > > Gentoo, much less outside. Thus its more a case study than anything > > benefiting anyone including myself. I will further it as I have > > interest and time permits. Still have a few more defects to address. > > > >
