what's performance difference between local xxx = require('xxx') and require('xxx') ?

xfwangcheers · 2016-12-08T16:45:48+00:00

We need to time out the request to proxy server when it exceeds 200ms regardless of connection issue or proxy processing time but sometimes it works as expec...

what's performance difference between local xxx = require('xxx') and require('xxx') ?

xfwangcheers

Hello

Why does the document https://github.com/openresty/lua-nginx-module#lua-variable-scope say:

Care must be taken when importing modules and this form should be used:
 local xxx = require('xxx')

instead of the old deprecated form:
 require('xxx')

Will the latter create a global variable eventually?

Thanks

kngrektor

I dont know it theres any perfomance difference.

The difference is instead in how you do modules.

New way: Populate a table with functions and return the table.

Old way: Call "module("mymodule", package.seeall)" which makes a global table and adds all subsequent globals to that table, It's confusing

You can read up on it here

But yeah, The latter will create a global variable.
Den torsdag 8 december 2016 kl. 09:45:48 UTC+1 skrev xfwang...@gmail.com:

Hello

Why does the document https://github.com/openresty/lua-nginx-module#lua-variable-scope say:
Care must be taken when importing modules and this form should be used: local xxx = require('xxx') instead of the old deprecated form: require('xxx')

Will the latter create a global variable eventually?

Thanks

aapo.talvensaari

On Fri, Dec 9, 2016 at 8:06 AM, Kng <kngr...@gmail.com> wrote:
> Den torsdag 8 december 2016 kl. 09:45:48 UTC+1 skrev xfwang...@gmail.com:
>> Why does the document https://github.com/openresty/lua-nginx-module#lua-variable-scope say:
>> Care must be taken when importing modules and this form should be used:
>> local xxx = require('xxx')
>>
>> instead of the old deprecated form:
>> require('xxx')
>>
>> Will the latter create a global variable eventually?

>
> I dont know it theres any perfomance difference.
>
> The difference is instead in how you do modules.
> New way: Populate a table with functions and return the table.
> Old way: Call "module("mymodule", package.seeall)" which makes a global table and adds all subsequent globals to that table, It's confusing
> You can read up on it here
>
> But yeah, The latter will create a global variable.

Polluting global namespace is bad. And local variables do have slight performance advantage. It is matter of index lookup vs. hash lookup. Index lookup is obviously a bit faster.

xfwangcheers

OK, thanks, I understand local var has better performance than global var.

OK. Let me explain my question more details

If I only need call require("xxx") to initialize but I don't need get its return result, should I declare a local var to store the require result if I don't need access it latter?

On Friday, December 9, 2016 at 5:51:49 PM UTC+8, Aapo Talvensaari wrote:

On Fri, Dec 9, 2016 at 8:06 AM, Kng <kngr...@gmail.com> wrote:
> Den torsdag 8 december 2016 kl. 09:45:48 UTC+1 skrev xfwang...@gmail.com:
>> Why does the document https://github.com/openresty/lua-nginx-module#lua-variable-scope say:
>> Care must be taken when importing modules and this form should be used:
>> local xxx = require('xxx')
>>
>> instead of the old deprecated form:
>> require('xxx')
>>
>> Will the latter create a global variable eventually?
>
> I dont know it theres any perfomance difference.
>
> The difference is instead in how you do modules.
> New way: Populate a table with functions and return the table.
> Old way: Call "module("mymodule", package.seeall)" which makes a global table and adds all subsequent globals to that table, It's confusing
> You can read up on it here
>
> But yeah, The latter will create a global variable.

Polluting global namespace is bad. And local variables do have slight performance advantage. It is matter of index lookup vs. hash lookup. Index lookup is obviously a bit faster.

itamar

To avoid polluting the global namespace, I think it would be best to store it to a temporary variable that you discard ( local ignored = require("xxx") )

-Itamar

On Mon, Dec 12, 2016 at 10:47 AM, <xfwan...@gmail.com> wrote:

OK, thanks, I understand local var has better performance than global var.

OK. Let me explain my question more details
If I only need call require("xxx") to initialize but I don't need get its return result, should I declare a local var to store the require result if I don't need access it latter?

On Friday, December 9, 2016 at 5:51:49 PM UTC+8, Aapo Talvensaari wrote:
On Fri, Dec 9, 2016 at 8:06 AM, Kng <kngr...@gmail.com> wrote:
> Den torsdag 8 december 2016 kl. 09:45:48 UTC+1 skrev xfwang...@gmail.com:
>> Why does the document https://github.com/openresty/lua-nginx-module#lua-variable-scope say:
>> Care must be taken when importing modules and this form should be used:
>> local xxx = require('xxx')
>>
>> instead of the old deprecated form:
>> require('xxx')
>>
>> Will the latter create a global variable eventually?
>
> I dont know it theres any perfomance difference.
>
> The difference is instead in how you do modules.
> New way: Populate a table with functions and return the table.
> Old way: Call "module("mymodule", package.seeall)" which makes a global table and adds all subsequent globals to that table, It's confusing
> You can read up on it here
>
> But yeah, The latter will create a global variable.

Polluting global namespace is bad. And local variables do have slight performance advantage. It is matter of index lookup vs. hash lookup. Index lookup is obviously a bit faster.

.

Best regards,

Itamar Gilad

CTO & co-founder, Metapacket

javier

On 12 December 2016 at 10:41, Itamar Gilad <it...@metapacket.com> wrote:

To avoid polluting the global namespace, I think it would be best to store it to a temporary variable that you discard ( local ignored = require("xxx") )

the one polluting the global namespace or not is the module itself, not how it's called.

IOW: the module can mess with the environment, either directly or by using the (deprecated) 'module()' function. if it does so, assigning to a local variable won't change that.

if it doesn't store anything on the global, then the only effect would be to return something, so you have to get that somewhere, typically on a local variable. if you don't, then it will be (almost) as if you hadn't require()'d it.

But since the original question stated that the return value wasn't needed, then it seems that the purpose of the module is to modify some part of the environment, not about the returned value; so doing the assignment or not wouldn't make any difference.

[*] "almost" because the require() function stores whatever the module returns in the 'packages.loaded' table.

Javier

xfwangcheers

ok, it makes sense, thanks.

On Monday, December 12, 2016 at 7:33:49 PM UTC+8, Javier Guerra wrote:

On 12 December 2016 at 10:41, Itamar Gilad <ita...@metapacket.com> wrote:
To avoid polluting the global namespace, I think it would be best to store it to a temporary variable that you discard ( local ignored = require("xxx") )

the one polluting the global namespace or not is the module itself, not how it's called.

IOW: the module can mess with the environment, either directly or by using the (deprecated) 'module()' function. if it does so, assigning to a local variable won't change that.

if it doesn't store anything on the global, then the only effect would be to return something, so you have to get that somewhere, typically on a local variable. if you don't, then it will be (almost) as if you hadn't require()'d it.

But since the original question stated that the return value wasn't needed, then it seems that the purpose of the module is to modify some part of the environment, not about the returned value; so doing the assignment or not wouldn't make any difference.

[*] "almost" because the require() function stores whatever the module returns in the 'packages.loaded' table.

--
Javier