Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006217OCamlOCaml backend (code generation)public2013-10-30 15:082014-12-06 00:06
Reporterppedrot 
Assigned To 
PrioritynormalSeveritytweakReproducibilityalways
StatusacknowledgedResolutionopen 
PlatformOSOS Version
Product Version4.01.0 
Target Version4.02.2+devFixed in Version 
Summary0006217: Compilation of record functional modification is costly
DescriptionCurrently, compilation of the { r with ... } expression seems to have a length threshold that triggers a change in the way it is compiled. For instance,

type t = {
  t1 : int option;
  t2 : int option;
  t3 : int option;
  t4 : int option;
  t5 : int option;
}

let set1 x t = {
  t with t1 = Some x;
}

produces a direct allocation on the minor heap, together with a bunch of assembly moves that copy the record fieldwise. Problem is, adding a [t6 : int option] field changes this to an [Obj.dup] followed by a [caml_modify].

I don't know if this has been decided with respect to some benchmarks, but [caml_modify] is really costly, and for the record (no pun intended), this overhead was indeed observable in Coq. Maybe this threshold should be incremented?
Tagsjunior_job
Attached Files

- Relationships

-  Notes
(0012139)
doligez (administrator)
2014-09-15 23:17

There is another problem with this: if the record is immutable it's possible that, in the near future, the call to [caml_modify] will break the GC's invariants.
(0012154)
bobot (reporter)
2014-09-17 10:50

The current heuristic is `3 + 2 * number_of_modified_file >= number_of_field` for the piece by piece copy (transl_record in translcore.ml)

Instead of modifying this heuristic and for taking into account Damien's comment, can't we just replace the setfield:

 `Psetfield(lbl.lbl_pos, maybe_pointer expr)` by
 `Psetfield(lbl.lbl_pos, false)`

Since we are sure that the values assigned are older than the duplicated record?
(0012674)
gasche (developer)
2014-12-06 00:06

Note: Fran├žois Pottier also hit this limit when experimenting with converting the Menhir parser generator from a mutable field update to a pure record update. While this comes at basically no cost if the state of the parser is a record of 5 fields, changing it to 6 fields gives an overall 30% performance overhead (in the generated parsers).

- Issue History
Date Modified Username Field Change
2013-10-30 15:08 ppedrot New Issue
2014-06-19 17:42 gasche Tag Attached: junior_job
2014-07-16 13:49 doligez Status new => acknowledged
2014-07-30 21:01 doligez Target Version => 4.02.1+dev
2014-09-04 00:25 doligez Target Version 4.02.1+dev => undecided
2014-09-15 23:17 doligez Note Added: 0012139
2014-09-15 23:17 doligez Target Version undecided => 4.02.2+dev
2014-09-17 10:50 bobot Note Added: 0012154
2014-12-06 00:06 gasche Note Added: 0012674


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker