Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[platform-core-dev] Szymon Ptaszkiewicz for Platform Workspace component co-lead

I would like to nominate Szymon Ptaszkiewicz as the component co-lead for Platform Workspace.
Szymon is the lead of Eclipse Support Center in Poznan/Poland. He already helps to handle daily process of running the component
and is very active as the Platform committer. I don't have as much time as I need to run the component alone, so I think it will be great help
and will make the difference during next development cycles.

Regards
--
Szymon Brandys
Eclipse Platform and Orion
Advisory Software Engineer
szymon.brandys@xxxxxxxxxx
(+48 12) 628 9857

            O
O R I O N
       O

IBM SWG Lab, Cracow, Poland
IBM Polska Sp. z o.o. oddział w Krakowie
ul. Armii Krajowej 18
30 -150 Kraków

NIP: 526-030-07-24
Sąd Rejonowy dla m.st. Warszawy, XIII Wydział Gospodarczy KRS
KRS 0000012941, Kapitał zakładowy: 34.650.000 PLN




From:        Martin Kočí <martin.kocicak.koci@xxxxxxxxx>
To:        "Eclipse Platform Core component developers list." <platform-core-dev@xxxxxxxxxxx>
Date:        2013-11-13 11:39
Subject:        Re: [platform-core-dev] [perf] org.eclipse.core.runtime.Path (computeSegments) : is cache possible ?
Sent by:        platform-core-dev-bounces@xxxxxxxxxxx




Hi,

I have more info about this problem.

1) My (test)cache in org.eclipse.core.runtime.Path.computeSegments retains ~ 250MB of (segments) String [] in my test case. I think this is a good trade off in this case : the ratio Memory/Cpu  is good.
A question : in there in equinox / eclipse platform a generic concurrent cache implementation with timeouts etc .. ?

2) After the build are in heap many instances of org.eclipse.core.runtime.Path (~100 000, retain 400MB) : those references aren't from my test-cache for org.eclipse.core.runtime.Path, but from eclipse self. It means, something holds already references to org.eclipse.core.runtime.Path permanently : I`ll  investigate it more.

3) URL : instances of java.util.URL are also ummutable like Path. The build creates also many, every time with same String-paths (the profiler marks the constructror of java.util.URL as hotspot)



2013/11/12 Martin Kočí <martin.kocicak.koci@xxxxxxxxx>
Hi,

hier is some background for this performance-problem: http://dev.eclipse.org/mhonarc/lists/platform-core-dev/msg01707.html (topic [perf] AbstractDataTreeNode.simplifyWithParent creates 100 mil instances during one build)

I've elimitated m2e and maven and now I have a 15min build in eclipse.

UseCase is: Build -> Clean -> Clean all projects.

The most allocations comes from  org.eclipse.core.runtime.Path.computeSegments and  org.eclipse.core.runtime.Path instance self : total 110GB (!) was allocated from org.eclipse.core.runtime.Path classes.

My quuestion is: is a cache for Path or segments or both possible ? Was this already discussed ?

A path is "/a/immutable/string":
As a quick proof of concept I've implemeted cache in org.eclipse.core.runtime.Path.computeSegments (key is String path) and for some invocation of new Path() (new method createPath(path)). The build time drops to 8 minutes with this patch = 2x faster.

Thank you for your answers


Martin
_______________________________________________
platform-core-dev mailing list
platform-core-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-core-dev


Back to the top