First Last Prev Next    No search results available
Details
: Bytecode reading is really slow for large programs
Bug#: 127
: libraries
: Bitcode Reader
Status: RESOLVED
Resolution: FIXED
: All
: All
: 1.0
: P2
: normal
: 1.1

:
: quality-of-implementation
:
:
  Show dependency tree - Show dependency graph
People
Reporter: John T. Criswell <criswell@uiuc.edu>
Assigned To: Chris Lattner <sabre@nondot.org>
:

Attachments


Note

You need to log in before you can comment on or make changes to this bug.

Related actions


Description:   Opened: 2003-11-18 13:57
The kimwitu++ program takes 60 seconds of user space time to print out its
version number and licesning information when run with the x86 JIT.  Either
Kimwitu++ is doing something extremely silly, or something is causing a
performance problem (either the JIT or the compilation from C++ to bytecode).
------- Comment #1 From Chris Lattner 2003-11-18 14:59:43 -------
This is a huge performance problem.  It doesn't look like it's the code
generator itself causing this: the code gen phases only take 5-10s or something
to run.

My personal guess is that it's the bytecode loader...

-Chris
------- Comment #2 From Chris Lattner 2003-11-18 23:14:01 -------
It takes 40s to just disassemble the bytecode file.  This seems bad...

-Chris
------- Comment #3 From Chris Lattner 2003-11-19 00:07:52 -------
Wow, this is fun.  kc++ has over 1200 types.  I think it's causing the type
resolution code to die...  hrm.

-Chris
------- Comment #4 From Chris Lattner 2003-11-19 11:30:35 -------
Here's a patch that helps cut the time to parse the .bc file in half:
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20031117/009643.html

kc++ -version now takes 33s in the JIT.  At least we're getting closer.

-Chris
------- Comment #5 From Chris Lattner 2003-11-19 13:13:45 -------
Here's another patch that chops the time to run kimwitu++ in the JIT effectively
in half again:
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20031117/009646.html

There are other minor improvements that can be made, but I think a 4x
improvement in bytecode loading speed is enough for now.  Note that these
changes should significantly reduce the time to link LLVM programs as well.

-Chris

First Last Prev Next    No search results available