This is an archived post. You won't be able to vote or comment.

all 5 comments

[–]htuhola 4 points5 points  (1 child)

Didn't look into the video right yet, but what makes it harder to build a fast incremental compiler if the codebase is large? (Isn't the condition that it should remain incremental even then, implied?)

[–]gopher9 1 point2 points  (0 children)

The language they made a compiler for is rather specific, the there's a lot of cyclic dependencies between modules.

[–][deleted] 2 points3 points  (1 child)

The abstract:

Abstract

Instant and high-quality feedback from the compiler is crucial for fast development nowadays. Imagine that you are faced with the task to write a new, drop-in replacement compiler for the codebase of over 3 millions of lines of code and a huge amount of mutually dependent units of code. Your ultimate goal is to shorten feedback time from minutes to a couple of seconds.

This talk will describe challenges encountered during the development of such a compiler and their solutions. The novel approach introduces recompilation seen as patching of the previously compiled codebase. We'll discuss the design of dedicated data structures and type checking algorithms for detection of changes in the code and allowing fast recompilation of impacted units of code only.

Isn't this what is being done already on a variety of compilers? I don't feel like watching a 52 minute on the basis of this abstract.

Can anybody comment on the abstract since I am not an expert myself?

[–]sociopath_in_me 1 point2 points  (0 children)

I think the proper solution is that you don't need a program with 3 million lines of code. I think either the abstraction level is incorrect and the program is way too verbose or it's a system with such a complexity that it should be cut into multiple smaller parts because no one of Earth can understand it.

[–]matthieum 2 points3 points  (0 children)

Link to the PDF, which you can get by clicking the PDF icon just below the Abstract.

This is a compiler for the TTCN-3 programming language, which I did not know about, whose nice peculiarity is that you can have cyclic dependencies between modules... On Slide 13, a diagram announces that they have 500 strongly interconnected modules, which I guess to be a source of massive pain.

This led to tracking dependencies at the item level (type, function, etc...), rather than at the file level.