# Possibility of \`local import\` statements in future?

**URL:** <https://discourse.julialang.org/t/possibility-of-local-import-statements-in-future/10611>\
**Category:** Internals & Design\
**Tags:** scope\
**Created:** [April 29, 2018, 8:41pm UTC](https://discourse.julialang.org/t/possibility-of-local-import-statements-in-future/10611 "2018-04-29T20:41:39Z")\
**Posts on this page:** 1\
**Showing post:** 47

<div class="post-metadata">

**Author:** ![chakravala](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chakravala/32/6832_2.png) [@chakravala](https://discourse.julialang.org/u/chakravala)\
**Post date:** [May 1, 2018, 1:15pm UTC](https://discourse.julialang.org/t/possibility-of-local-import-statements-in-future/10611/47 "2018-05-01T13:15:25Z")

</div>

To update on what’s happening with the implementation, I made a comparison of load times using the original form of extending the `Base` functions and the new way of containing them locally. There is performance gain.

On the original [master](https://github.com/chakravala/Reduce.jl) branch, the compile cache is `2.5 MiB` and the load time is

```nohighlight
julia> @time using Reduce
Reduce (Free PSL version, revision 4588), 28-Apr-2018 ...
 11.211845 seconds (7.25 M allocations: 402.106 MiB, 3.00% gc time)

```

While on the [force-user](https://github.com/chakravala/Reduce.jl/tree/force-user) brach, the compile cache is `1.7 MiB` and the load time is

```nohighlight
julia> @time using Reduce
Reduce (Free PSL version, revision 4588), 28-Apr-2018 ...
  6.455135 seconds (3.57 M allocations: 191.129 MiB, 4.70% gc time)

```

This difference can be attributable to the fact that the package contains definitions for over 50 conflicting methods from `Base`, such as arithmetic, matrix, trigonometric, and other elementary / special functions.

With the new definitions, the original dispatch from `Base` is essentially reduced down to a single one that encapsulate all of the `Base` methods, plus the additional new ones defined by the package.

Now, the multiple-dispatch is handled completely differently, which is why the tests are failing. The multiple-dispatch had to be very finely tuned to be in harmony with `Base`, and there were no issues or conflicts due to the precise fine tuning of the dispatch. However, since a simpler dispatch is now used using the

```nohighlight
module Algebra
    export +
    +(r...) = Base.:+(r...)
end

```

using that form extension causes havoc on the multiple dispatch, since it was so finely tuned to work with the hundreds of existing methods from `Base`. This means that they fine tuning of dispatch has to be started over, since none of the dispatch structure from `Base` could be copied over to the new module.

---

_[View the full topic](https://discourse.julialang.org/t/possibility-of-local-import-statements-in-future/10611)._