Re: [jamboost] Re: Performance & import

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-06-05 09:39:56

David Abrahams wrote:
> Vladimir Prus <ghost_at_[hidden]> writes:
> > David Abrahams wrote:
> >> > The 'modules.mormalize-raw-paths' takes more time than actually
> >> > building targets! I think that now that "import" is required in every
> >> > class, and is called during construction of all instances, we *really*
> >> > need to optimize it -- and in particular, it should not call
> >> > 'normalize-raw-paths' in such a way. Thoughs?
> >>
> >> I think we should optimize normalize-raw-paths; it would be easy to
> >> make a cache of results or to stop work on a path when all of its '.'
> >> characters have been processed. I think the cache is probably the
> >> way to go, though.
> >
> > First off, I think there's no point to normalize all those paths, unless
> > you're really going to load the module.
>
> The point of normalizing the path is that we don't want to change the
> load priority order for directories which are already in
> BOOST_BUILD_PATH, because it would result in highly unpredictable
> behavior if a different module could be loaded based on the directory
> of the module doing the loading. You can only detect that if you can
> compare the paths effectively.

I don't think this logic prevents confusion. Say "a", "b" and "c" are in 
search path. Both "a" and "c" has module "m.jam". Say directory "d",
not yet in path, has modules "m.jam" too.
- if you import "m" from module in directory "a" --- "a/m.jam" is used
- if you import "m" from module in directory "c" --- "a/m.jam" is used,
by the current logic
- if you import "m" from module in directory "d" --- "d/m.jam" is used.

Hmm... and who do you tell if "import" in "c" or "import" in "d" is executed 
first? 

Another question: is user *ever* supposed to override standard modules, merely 
by placing files of the same name in this project? Maybe, the additional path 
should be added at the *end* of search path? 

> > The attached patch reduces the number of 'normalize-raw-paths'
> > invocations from 1544 to 76, which translates into considerable
> > run-time reduction.
>
> Great!

Ok, I'll commit it soon.

> > After than, caching can help, but:
> > 1. I don't really understand why we need to use 'normalize-raw-paths'.
> > When I change it to return its argument, all tests pass for me on Linux.
>
> Explained above.

OK, discussed above. In fact, a use case that 'normalize-raw-paths' fixes (i.e 
a test) is still desirable. I understand this might not be high-priority, but 
still...

> > 2. It's not that good idea to duplicate functionality already in
> > path.jam.
>
> The implementation of path.join (which is close to what that rule
> does) is so complicated that I had no confidence that it was doing
> what I wanted, 

It has some tests, after all.

> plus it would have drawn path.jam into the kernel, 

Not sure code duplication is better.

> plus
> I didn't want to translate the path to the internal path format and
> back to native just to get this job done. 

In fact, 'normalize-raw-paths' does it! It converts raw path into internal 
path format. 

> Feel free to find a better solution.

Provided that 'normalize-raw-paths' is needed, it's better to move 'path.jam' 
to 'kernel' and call 'path.make' in a loop from 'normalize-raw-paths', IMO.

- Volodya