Slowness in conv() in 0.9.4.4

[Giancarlo Niccolai]

This is for Klaim ;-)

During 0.9.2-4 versions, we used to break from an inner frame via a
very simple exception (an integer) thrown from within the code. Inner
frames are quite rare in Falcon, as we usually manage call frames via
flat loops in the VM. They are mainly used for toString() conversions
and other relatively rare operations.

One of the thing using it, both for simplicity and -supposedly-
performance was conv() method. But we noticed that it was
exceptionally slow for massive operations.

No, stack unroll at exception throw should be quite light;
algorithmically (and in terms of generated binary code) it has even
less complexity than using other means, as i.e. keeping a list of
resources to be freed. But, massive usage of exceptions in a short
time seems to add an overhead that doesn't depend on executed code,
and has rather a basis on the exception-per-time-unit count; the
relation is lose, but the effect is evident: code using that is about
10 times slower what it should be.

So, we already removed that code from SVN, and now exceptions are
thrown only in case of errors.

[Klaim]

Nice ;D

I looked at the code at that time I was saying it wasn't a really good solution, but couldn't found a "better" (read "clean and elegant") solution so I couldn't help on this (did try some fixes but they were too naive).
So, how did you replace the exceptions? Some kind of return value system?

Klaim

[Giancarlo Niccolai]

On 11 Nov, 11:17, Klaim <mjkl...@gmail.com> wrote:
> Nice ;D
>
> I looked at the code at that time I was saying it wasn't a really good
> solution, but couldn't found a "better" (read "clean and elegant") solution
> so I couldn't help on this (did try some fixes but they were too naive).
> So, how did you replace the exceptions? Some kind of return value system?
>
> Klaim
>

In the beginning, I wanted do adapt the throws to the early "VM event"
mechanism; that is, there was a various set of events that a script
may have sent to a VM for remote evasion. For example, the "suspend"
event required all the frames to exit to give the control back to the
topmost caller, possibly an embedding application, to allow it push
new data in the script. "Single step" was another event, and errors
was all VM events.

Then it came the need to raise errors even when a VM was not around,
and try/catch is a quite handy way to do that. Even LUA now manages
errors in the same way, (well, a bit more low level as they are C and
so need to manually use setjmp/longjmp, but the inner CPU mechanism
used is the same).

The model is now superseeded by more specific plugs (i.e. the async
message system, direct error throwing, VM inheritance and virtual step-
by-step method plugs), so the only event still in place was the
"return from current frame" event and the "quit the VM now". The
latter one is practically generated only by the exit() function, which
is hardly if ever called, and is still a throw.

For the frame return, as it is an internal VM-to-VM notify (the VM
finds that a frame terminates a local set of sub-frames, and need to
exit the main loop), setting a global variable in the VM is ok. The
only problem is that it adds an extra check in the while() loop, that
is not anymore a while(true), but it weights something around 1/100th
and 1/1000th of every VM loop, and VM loops weight about 1/20th to
1/500th of a real-world application.

... we can afford the extra check.

[Maik]

A note on exception performance on Windows:
In the back of my mind, I memorize a comment made by a Microsoft guy
(I believe in a video from http://www.nwcpp.org/) on the cost of
exceptions. While throwing them on Win32 it quite efficient, on Win64
its _much_ more expensive.

One more reason use exceptions as an error mechanism that doesn't
clutter the interface, but not for well defined runtime behavior.

I know, this smart ass comment doesn't design a good interface, does
it? :P

So keep up the good work!

Best,
-- Maik