lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

> Please, reread my last post. I wasn't arguing about raw speed, but about
> weight/speed ratio, where (maybe confusingly, I admit) "weight" means "code
> size".

The patch doesn't force you to use function instead string,
so the choice is up to developer.
Here's the example how weight may be decreased by using functions:

function open_db ()
   local internal_name = "handle 'plum'"
   local internal_handle = something ()

   local self = {}

   local function make_error_message ()
      return 'Encountered error while processing
"'..iternal_handle..'": '..internal_handle.get_last_error ()

   function self.get_a (arg1)
      return assert (internal_handle.get_something ("asdfasdf", arg1),
   function self.get_b (arg1, arg2)
      return assert (internal_handle.get_something2 ("sdlkfj", arg1,
arg2), make_error_message)
   function self.do_a ()
      assert (internal_handle.do_1 (), make_error_message)
   function self.do_b ()
      assert (internal_handle.do_2 (), make_error_message)

   return self

> Lua authors have repeatedly stated on this list that, although Lua speed is
> important, Lua code size is important too.

As you can see, we've got 5 complexly interconnected variables here:
1) assertion success case execution speed
2) assertion failure case execution speed
3) Lua source code size
4) Lua VM code size (PUC or JIT)
5) Machine code size of 'assert ()'

> You seem concerned only about speed, which is rightful, but Lua is used, for
> example, also by people working on embedded systems, who perhaps may have a
> different view on what's important. Since you are proposing to change
> something used by everybody, IMHO, my (mild) objection is relevant.

Actually, yes:) Speed is what I usually prefer due to specifics of my projects.