Saturday, January 21, 2006

How to speed up eclipse on a Laptop: disable virus-scanner, partition disk, upgrade memory

I have a Dell Lattitude 600 with 1GB of memory. Starting eclipse and building workspaces is slow. So I was looking for ways to improve speed. Here is what I did over time:

  • Disabled the virus scanner for the eclipse directory and the workspace. McAfee's on-access-scan scans the entire file when a process accesses it. When eclipse starts is only reads small fractions of .jar files. However McAffee scanned the entire file which really slows down start-up by a factor of 2: cold start-up (=newly booted machine) 95 sec without versus 215 secs with virus scanner on.
  • Partitioned my disk: I tried all kinds of defragmentation (oodefrag and diskkeeper), but nothing really helped, some made it even worse.. However one problem is that compiling creates new files and that leads to new fragmentation. Now I created a relatively small partition with my workspace. Even if this gets totally fragmented, the disk head in confined within the partition. It gave me some speedup, but I have not measured it, but it was dramatic. I wish there was a defragmentation tool, that could observe the startup of eclipse and then rearrange the files so that the access is optimal. I know such tools exist for the startup .exe files, but we need something for the startup of a system like eclipse....
  • Upgraded the memory to 2Gb and disabled the page file: Yesterday, I did the upgraded and it's great. With 2 eclipse open, outlook, trillian, thunderbird, firefox, and a few other programs, I use about 1.5Gb of memory with enough space for the disk cache. That's a real blast: because no application gets paged out anymore, I don't have to worry about switching between applications. No more long interruptions when eclipse garbage collects. It's so new, I still can't believe that I don't have to wait anymore when I switch between applications. And 2 workspaces open in parallel is no problem anymore....

In a nutshell: It's all about minimizing disk access.

Tuesday, January 17, 2006

MDSD: A European Phenomenon?

Yesterday, I wrote about my confusion with the 4 metamodel layers of MOF. Ed Willink )GB!) pointed me to a nice (French) paper about MOF. Their application of the layer is very similar to my understanding :-).

When searching for concepts around MOF and MDSD there very many European hits:

Is this a European Phenomenon? There is a kind of pattern: many new concepts are invented and researched in Europe, but commercial success often comes when American companies pick it up....

I am confused by OMG MOF 4 layers applied to MDSD and UML...

Today I tried to explain to some colleges the 4 layers of the OMG Meta-Object Facility (MOF). At first it sounds quite trivial:

  • Level M0: User Object Layer (Instances)
  • Level M1: Model (DSL – Domain Specific Language)
  • Level M2: Meta-Model (Schema description Language)
  • Level M3: Meta-Meta-Model (The Schema of the Schema)

Surprisingly applying the levels to concrete problems is not always obvious or straight forward.
I used the plugin.xml file as an example. I take here a MDSD centric approach, by assuming that the plugin.xml file "generates" the plugin....
  • Level M0: (Instance) The deployable component
  • Level M1: (Model) The plugin.xml file itself
  • Level M2: (Meta-Model) The extension point schema description (.exsd) files
  • Level M3: (Meta-Meta-Model) Schema of the .exsd files (implemented somehow in the .exsd editor)

Someone (a compiler person) asked me, how I would apply this to a programming language like C.
  • Level M0: (Instance) Executable code
  • Level M1: (Model) .C file (or a AST (Abstract Syntax Tree) representation)
  • Level M2: (Meta-Model) C language syntax definition (e.g. in yacc)
  • Level M3: (Meta-Meta-Model) Yacc language syntax definition

In this case, the meta model describes the constraints on the are AST (that's what the CDT does). This shows, that it makes sense to have a DSL (Domain Specific Language) at some levels. The DSL of C is simply the c syntax. The DSL of the c-syntax is yacc (or EBNF)... It is also interesting to have transformation between different representations of a model at the same level. C versus AST, yacc versus EBNF... The "code generation" happens between M1 and M0 (compiling). Another code generation happens between M2 and M1 when using a compiler-compiler like yacc.

But whenever I read about UML and MOF I get confused. This might have to do with the fact that I never really used UML....
  • Level M0: (Instance) Generated C/Ada code
  • Level M1: (Model) Concrete UML diagrams
  • Level M2: (Meta-Model) UML "language"
  • Level M3: (Meta-Meta-Model) ??

Again, a generator/transformer is applied between M1 and M0. Is this a correct application of MOF to UML?

But explaining both (the MDSD and the UML approach) to someone who has not been exposed to modeling gets very confusing.

So, in "my world" I prefer to see the MOF hierarchy very MDSD centric. I wonder if the MDSD centric view is confusing for UML experts is is the a natural way to see the world....