Re: Slow loadstring problem
- From: "Jonas R." <jonas.efternamn@xxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Fri, 11 Jan 2013 02:19:32 +0100
Hi,
I don't have access to a computer at the moment, so I haven't been able to
test it myself;
Have you tried -joff? I can imagine the jit compiler would take a while to
plow through a 50mb file.
/jonas
Den 10 jan 2013 23:54 skrev "Ben Rog-Wilhelm" <zorba-luajit@xxxxxxxxxxxxx>:
>
> I’ve got a 50mb lua file that takes about two seconds to load in Lua 5.2.
> Unfortunately, it takes about two *minutes* to load in Luajit 2.0. I
> haven’t been able to figure out what’s going on in detail. Lua 5.1.4 errors
> out with “constant table overflow”, so maybe this isn’t intended to be
> supported on LuaJIT, but we’re actually using “can the lua environment load
> it” to tell us if the output file is parseable. As it is, a two-minute
> delay has turned into a rather large problem for us.
>
> The file is available at
> http://www.pavlovian.net/lj/**luajit_slowload.zip<http://www.pavlovian.net/lj/luajit_slowload.zip>(3mb
> download, unpacks to 50mb). I’m testing with the following
> vaguely-accurate test harness:
>
> local s = os.time() local str = loadfile("data.lua") local e = os.time()
> print(string.format("%d to parse", e - s))
>
> Lua 5.2.1: 2 to parse, 0 to run
> LuaJIT 2.0: 140 to parse, 0 to run
>
> (Obviously this doesn’t separate load time from parse time, but load time
> should be quite minimal – in our actual application we’re loading it
> straight out of memory and we see the same issue.)
>
> We’re building LuaJIT under MSVC2008 as a 32-bit package and comparing it
> against the binaries from luabinaries.sourceforge.net, I haven’t tested
> on any other platforms yet. I did run a profiler on it – virtually all the
> CPU usage is occurring in children of lj_parse_keepstr. About 60% of it is
> within lj_str_new with the remaining 40% in lj_tab_setstr. These may be
> somewhat inaccurate due to inlining, however.
>
> Any way I can help fix this without knowing the codebase? I’m somewhat
> scared of digging into the code and I’m hoping the fix is simple now that
> the problem is reproducible :)
>
> Thanks,
>
> -Ben
>
>
Other related posts:
