D45 Scalability: Difference between revisions
imported>Tommy |
imported>Tommy |
||
Line 17: | Line 17: | ||
:* failures occuring on windows platforms, the mostly used system, when reaching the operating system limit number of graphical elements in memory allowed to be displayed at once. This bug used to crash the Rodin platform, and it appeared necessary to control the number of graphical elements needed to display the model elements. Architectures sparing these graphical elements should be thus favoured. | :* failures occuring on windows platforms, the mostly used system, when reaching the operating system limit number of graphical elements in memory allowed to be displayed at once. This bug used to crash the Rodin platform, and it appeared necessary to control the number of graphical elements needed to display the model elements. Architectures sparing these graphical elements should be thus favoured. | ||
:* failures due to the high consumption of memory by the heavy graphical elements used by the forms of legacy editor. | :* failures due to the high consumption of memory by the heavy graphical elements used by the forms of legacy editor. | ||
Moreover, it appeared important to visualize some elements that are not part of the current level of modelling, but are linked to it. | Moreover, it appeared important to visualize some elements that are not part of the current level of modelling, but are linked to it, for exemple, the actions in an abastract event, or its guards. Such elements are called the "inherited" elements, or "implicit children". The legacy structured editor being directly interfaced with the underlying Event-B models in database, it was difficult and tricky to display inherited elements. Hence, it was one more argument to go for a new editor, this time based on a intermediary representation of the models. | ||
* The motivations about Camille evolution {{TODO}} Ingo Weigelt. | * The motivations about Camille evolution {{TODO}} Ingo Weigelt. |
Revision as of 14:47, 21 November 2011
Overview
- Improved Performance According to the refocus mentionned in the General Platform Maintenance chapter, much of the reworking efforts performed on the core plateform basically aimed to overcome Rodin scalability weaknesses, and the continuous need of seamless proving experience. The whole performance was enhanced by core implementation and user interface refactorings. Improvements made to the proving experience will be detailed in a separate chapter.
- TODO An overview of the contribution about the design pattern management / Generic Instantiation (Thai Son Hoang)
- Edition It appeard along DEPLOY, the models defined by pilots becoming industrial sized due to the level of complexity reached, that the edition became a central concern.
- The legacy structured editor based on a form edition specific achitecture reach its limits in responsivness and hence in usability when being constrained to display a huge amount of graphical elements.
- Camille textual editor had to tackle challenges related to ressources mapping and management for projects of industrial size mentionned above or even the design of extension capabilities, that became a major concern since the grammar could be extended with theories.
Motivations
Improved Performance
It appeared that the various DEPLOY partners encountered several major issues while editing large models. Some were related to the core code of the Rodin platform, causing crashes, loss of data, corruption in models. Some other were related to the UI causing platform hanging, and sometimes leading to its freezing which required sometimes to kill the Rodin process, thus also leading to potential loss of data and corruption in models. Hence, it appeared necessary to solve such issues before the end of DEPLOY.
Design Pattern Management / Generic Instantiation
TODO To be completed by Thai Son Hoang
Edition
- The motivations behind the creation of the new textual structured editor mainly concern performance but not only. From the growing size of complexity reached in models inducing a growing of their physical size lead the platform to its limits. Two major kinds of failures were faced when developing such models:
- failures occuring on windows platforms, the mostly used system, when reaching the operating system limit number of graphical elements in memory allowed to be displayed at once. This bug used to crash the Rodin platform, and it appeared necessary to control the number of graphical elements needed to display the model elements. Architectures sparing these graphical elements should be thus favoured.
- failures due to the high consumption of memory by the heavy graphical elements used by the forms of legacy editor.
Moreover, it appeared important to visualize some elements that are not part of the current level of modelling, but are linked to it, for exemple, the actions in an abastract event, or its guards. Such elements are called the "inherited" elements, or "implicit children". The legacy structured editor being directly interfaced with the underlying Event-B models in database, it was difficult and tricky to display inherited elements. Hence, it was one more argument to go for a new editor, this time based on a intermediary representation of the models.
- The motivations about Camille evolution TODO Ingo Weigelt.
Choices / Decisions
Improved Performance
SYSTEREL lead a two phase investigation to have a better idea of the work to be done. Each phase being followed by some refactoring of the code. Out of the early investigation, a cause and effect relationship has been found between perfomance loss and the various reported bugs, such as "platform hanging" bugs or even "no more handle" bugs related to the high consumption of graphical elements on Windows platforms. Indeed, it appeared that solving the performance issues sometimes solved induced bugs as well which made the scalability improvement tasks emcompass the maintenance goals.
Later, a deeper investigation was performed, to indentify and tackle the remaining performance issues. Profiling and code review were the two techniques used. The profiling strategy allowed to get a better localisation of the performance loss in both UI and core code while the code review helped to understand the intrinsic misuses or drawbacks of particular components and/or architectures.
A good example, was the Event-B built-in editor based on form editors with a high use of greedy graphical components. Such architecture appeard to be weak when it was needed to display industrial size models. This affected the modelling experience with some long, and really annoying to the user, reaction lags. To solve such issue, it has been chosen to refactor the editors using a textual representation which was a light-weight graphical alternative to lower the number of needed components.
Design Pattern Management / Generic Instantiation
TODO To be completed by Thai Son Hoang
Edition
- About the Text Editor TODO Ingo Weigelt
Available Documentation
- TODO Links for Improved Performance
- TODO Links for Design Pattern Management / Generic Instantiation
- TODO Links for Edition
Status
Improved Performance
The refactoring made on both core code and UI code allowed to gain up to 25 times speed-up on the UI, and almost a 2 times speed-up in the core code, making the platform usable in an industrial sized context.
Design Pattern Management / Generic Instantiation
TODO To be completed by Thai Son Hoang
Edition
TODO To be completed by Thomas Muller, Ingo Weigelt