Skip to content

ParserCombinator is slow #22

@CarloLucibello

Description

@CarloLucibello

I did some perfomance tests for reading a file from a graph using my package FatGraphs;

Pkg.clone("https://github.com/CarloLucibello/FatGraphs.jl")

For comparison I write a graph in a simple text format (Pajek .net). Each of the following function has been run twice to avoid compilations times:

julia> g = Graph(100,1000,seed=1)
Graph{Int64}(100, 1000)

julia> @time writegraph("test.net",g)
  0.243075 seconds (37.02 k allocations: 1.487 MB)
1

julia> @time readgraph("test.net")
  0.003040 seconds (18.54 k allocations: 550.281 KB)
Graph{Int64}(100, 1000)
```
Notice how  perfomance is degraded  when **reading** from a .dot or a .gml file, relying on ParserCombinator:
```julia
julia> @time writegraph("test.dot",g)
  0.001826 seconds (15.23 k allocations: 664.031 KB)
1

julia> @time readgraph("test.dot")
  2.408855 seconds (1.22 M allocations: 49.666 MB, 0.56% gc time)
Graph{Int64}(100, 1000)


julia> @time writegraph("test.gml",g)
  0.001426 seconds (16.83 k allocations: 789.031 KB)
1

julia> @time readgraph("test.gml")
  1.024898 seconds (511.11 k allocations: 18.279 MB, 0.64% gc time)
Graph{Int64}(100, 1000)
```
Probably ParserCombinator has some huge type instability issues. Can those be avoided?

Bye,
Carlo 

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions