Would there be any performance boost from using one of the function. Is there a internal difference from using these two function, if so what are they.
dofile, loadfile and loadstring all call the same primitive to parse scripts.
I assume you mean loadstring(file:read("*a")). In this case, there may be a small performance hit (which I haven't measured) because Lua has to store the whole contents of the file as a string. The primitive that parses scripts does not do that: it reads the input in pieces.
Related
I am creating a game in love2d (LuaJIT) and I am creating a debug window for changing values at runtime. I was able to do that, however, I also now want to be able to call functions. For example, I traverse a table and there is a function in this table called "hello" which is written like this:
self.hello = function(str, num)
print(string.format("%s: %d", str, num))
end
From the expression of type(object.hello) I only see function. If it had been a table, I could have traversed it and see the keys and values, but it is just a "function" and I have no idea how to properly call it, as I don't know what arguments does it take and how many. Is there a way to find this out at runtime in lua? Maybe this information is also stored in some table elsewhere?
it is just a "function" and I have no idea how to properly call it
Neither does Lua. As far as Lua is concerned, any Lua function can take any number of parameters and return any number of parameters. These parameters could be of any type, as could its return values.
Lua itself does not store this information. Or at least, not in any way you could retrieve without doing some decompiling of its byte-code. And since you're using LuaJIT, that "decompiling" might require decompiling assembly.
For algorithms that support line by line processing, lua documentation suggests that using io.lines() is more efficient than io:read("*line") in a while loop.
The call io.read("*line") returns the next line from the current input
file, without the newline character. (...) However, to iterate on a
whole file line by line, we do better to use the io.lines iterator. (21.1 – The Simple I/O Model)
I can imagine three possible reasons that the io.lines() call is preferred.
The iterator is more efficient than the while loop
The file reading is handled more efficiently
It's easier to read/maintain the code
The lua documentation also promotes slurping files
(Y)ou should always consider the alternative of reading the whole file
with option "*all" from io.read and then using gfind to break it up (21.1 – The Simple I/O Model)
Hypothesis: io:read("*line") streams the file. If slurping is more efficient in lua, and io.lines() slurps the file, then io.lines() might be more efficient for that reason.
However, the unofficial Lua FAQ has the following to say about io.lines()
Note that it is an iterator, this does not bring
the whole file into memory initially.
This suggests streaming instead of slurping.
TLDR Does io.lines() ever hold the whole file in memory or does it only hold one line in memory at a time? Is its memory usage different than io:read("*line") in a while loop?
io.lines() does not hold the whole file in memory: it reads the file one line at a time, not the whole file at once. For that, use io.read("*all").
I'm trying to parse a very large file using FParsec. The file's size is 61GB, which is too big to hold in RAM, so I'd like to generate a sequence of results (i.e. seq<'Result>), rather than a list, if possible. Can this be done with FParsec? (I've come up with a jerry-rigged implementation that actually does this, but it doesn't work well in practice due to the O(n) performance of CharStream.Seek.)
The file is line-oriented (one record per line), which should make it possible in theory to parse in batches of, say, 1000 records at a time. The FParsec "Tips and tricks" section says:
If you’re dealing with large input files or very slow parsers, it
might also be worth trying to parse multiple sections within a single
file in parallel. For this to be efficient there must be a fast way to
find the start and end points of such sections. For example, if you
are parsing a large serialized data structure, the format might allow
you to easily skip over segments within the file, so that you can chop
up the input into multiple independent parts that can be parsed in
parallel. Another example could be a programming languages whose
grammar makes it easy to skip over a complete class or function
definition, e.g. by finding the closing brace or by interpreting the
indentation. In this case it might be worth not to parse the
definitions directly when they are encountered, but instead to skip
over them, push their text content into a queue and then to process
that queue in parallel.
This sounds perfect for me: I'd like to pre-parse each batch of records into a queue, and then finish parsing them in parallel later. However, I don't know how to accomplish this with the FParsec API. How can I create such a queue without using up all my RAM?
FWIW, the file I'm trying to parse is here if anyone wants to give it a try with me. :)
The "obvious" thing that comes to mind, would be pre-processing the file using something like File.ReadLines and then parsing one line at a time.
If this doesn't work (your PDF looked, like a record is a few lines long), then you can make a seq of records or 1000 records or something like that using normal FileStream reading. This would not need to know details of the record, but it would be convenient, if you can at least delimit the records.
Either way, you end up with a lazy seq that the parser can then read.
I need to handle large numbers in Lua which goes with Redis. Normally you would do that like:
require"bc"
bc.mul(...)
bc.mod(...)
etc.
But unfortunately Redis Lua doesn't support "require". The only approach I've found is inserting a large numbers library written in lua itself directly into the script.
The only such library I could get my hands on: oss.digirati.com.br/luabignum/index.htm
I can strip the library for the purposes of a concrete script but it still remains huge. Is there any way to handle large numbers in Redis Lua more efficiently?
UPDATE1: What if I save the whole library into a key and then access it like:
local BigNumLib = KEYS[1];
BigNumLib.BigNum.mul(KEYS[2],KEYS[3]);
I'm not sure of the syntax and perhaps I'll need to enclose all the library in a lua table {}.
I'm not familiar with how Redis handles Lua code, but why is inserting the library itself into your code is a problem? you should be able to do something like this:
local bc = function()
-- insert the code of BigNum.lua here
return BigNum
end
bc.mul(....)
The code has probably been written before Lua 5.1, so I don't know if there are any compatibility issues, but this should at least give you a start.
This may be a naive question, and I suspect the answer is "yes," but I had no luck searching here and elsewhere on terms like "erlang compiler optimization constants" etc.
At any rate, can (will) the erlang compiler create a data structure that is constant or literal at compile time, and use that instead of creating code that creates the data structure over and over again? I will provide a simple toy example.
test() -> sets:from_list([usd, eur, yen, nzd, peso]).
Can (will) the compiler simply stick the set there at the output of the function instead of computing it every time?
The reason I ask is, I want to have a lookup table in a program I'm developing. The table is just constants that can be calculated (at least theoretically) at compile time. I'd like to just compute the table once, and not have to compute it every time. I know I could do this in other ways, such as compute the thing and store it in the process dictionary for instance (or perhaps an ets or mnesia table). But I always start simple, and to me the simplest solution is to do it like the toy example above, if the compiler optimizes it.
If that doesn't work, is there some other way to achieve what I want? (I guess I could look into parse transforms if they would work for this, but that's getting more complicated than I would like?)
THIS JUST IN. I used compile:file/2 with an 'S' option to produce the following. I'm no erlang assembly expert, but it looks like the optimization isn't performed:
{function, test, 0, 5}.
{label,4}.
{func_info,{atom,exchange},{atom,test},0}.
{label,5}.
{move,{literal,[usd,eur,yen,nzd,peso]},{x,0}}.
{call_ext_only,1,{extfunc,sets,from_list,1}}.
No, erlang compiler doesn't perform partial evaluation of calls to external modules which set is. You can use ct_expand module of famous parse_trans to achieve this effect.
providing that set is not native datatype for erlang, and (as matter of fact) it's just a library, written in erlang, I don't think it's feasibly for compiler to create sets at compile time.
As you could see, sets are not optimized in erlang (as any other library written in erlang).
The way of solving your problem is to compute the set once and pass it as a parameter to the functions or to use ETS/Mnesia.