Re: "to" vs "method"

Thomas Leonard <[email protected]>
Newsgroups gmane.comp.lang.e.general
Message-ID <[email protected]>
On 3 April 2010 10:38, Kevin Reid <[email protected]> wrote:
> On Apr 3, 2010, at 5:06, Thomas Leonard wrote:
>
>> I just discovered that there are two ways of defining a method in E:
>>
>> def foo1 {
>>       to run() { return 3 }
>> }
>>
>> def foo2 {
>>       method run() { 3 }
>> }
>
> Yes. 'method' is intended as the 'internal' Kernel-E definition which
> doesn't magically bind any nouns. (For example, the expansion of fn {}
> does not use 'to'-equivalent.)
>
>> Interestingly, calling foo2() is between 3 and 10 times faster than
>> calling foo1(), depending on how deeply nested the call is:
>> ...
>> I guess this is because "to" uses __return, which is implemented by
>> throwing an exception in Java (so speed depends on the size of the
>> stack).

(note: I see Ejection overrides fillInStackTrace to do nothing, so I'm
not sure why it does depend on the stack depth now)

> Yes. Of course, an optimizing implementation should be able to
> eliminate this cost, either by recognizing that no nonlocal exit is
> necessary (the just-returning-a-value case) or by compiling simple
> cases into a cheap jump.

On further investigation, E already tries to do this optimisation (but
fails due to changes since it was written). I've put a patch up here:

http://gitorious.org/repo-roscidus/e-core/commit/b12fb657b92a376b264c45ca861b1d827af2c50e

Another change that helps a bit is getting ImportLoader to share the
slots in safeScope among all files in a vat:

http://gitorious.org/repo-roscidus/e-core/commit/e65743dae76a6d58c16f44af567b2d3c7ddaeb93

Together, they make my program about 10% faster.

I also tried removing the synchronized keyword from ImportLoader and
LazyEvalSlot (since they're no longer shared between threads) but that
didn't make any noticeable difference.

> E-on-CL does both (well, the latter provided the underlying CL
> cooperates).



-- 
Dr Thomas Leonard		ROX desktop / Zero Install
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.