[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: AW: [ve-dev] VE with XML Persistence
|
I assume that you are using VE 1.1?
First time (cold) bring up, will require
you to launch a target VM for the editor, and (if it is a first time ever
opening a particular file), a reverse parse, and most likely introspection
(which requires another target VM launch).
Reverse parsing, and introspection is
cached (and removed on a project clean), hence next open will not require
this path.
When you drop a new widget that was
not introspected yet, introspection (and possibly target VM launch) will
take place.
Do you see performance issues after
you have opened, and closed a file for the first time (where introspection/reverse
parse is not needed anymore), and a a spare VM is ready on standby to open
an editor?
If performance is acceptable in the
later case, it is possible to prime the cache/VM on startup.
If not, there is a way to "not"
use a target VM, and run inside the IDE; it is significantly faster as
you do not need to launch any VM (Disk bound), and introspection data is
not passed using TCP/IP - it introduce other limitations (class shape changes,
and the version level of the target image will be that of the IDE).
------------
Dr. Gili Mendel
IBM
Software Development
RTP Raleigh, NC
(919)543 6408, tie: 441 6408
HÖSS.Alexander <A.HOeSS@xxxxxxxxxxxxx>
Sent by: ve-dev-bounces@xxxxxxxxxxx
09/09/2005 07:25 AM
|
Please respond to
Discussions people developing code for the Visual Editor project |
|
|
To
| "Discussions people
developing code for the Visual Editor project" <ve-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
| AW: [ve-dev] VE with XML
Persistence |
|
Hi Joe,
the startup time isn't very important
to us. More important is to improve the performance of dropping new widgets
from the palette and editing these widgets graphically. These actions are
still a little bit slow on my workstation (1,8 GHz, 1 GB RAM) and the target
platform of our new product won't be as fast as my machine. So we are looking
for solutions to improve the described performance issues. Can another
persistence strategy help me out of that? Do you have other ideas how to
improve the performance?
Thanks a lot for your help.
Alexander
Von: ve-dev-bounces@xxxxxxxxxxx [mailto:ve-dev-bounces@xxxxxxxxxxx]
Im Auftrag von Joe Winchester
Gesendet: Freitag, 09. September 2005 12:32
An: Discussions people developing code for the Visual Editor project
Betreff: Re: [ve-dev] VE with XML Persistence
Hi Alexander,
There are people who have used the IDE successfully for XML serialization
- Canoo with Ultra Lightweight Client (www.canno.com/ulc), AUIML (http://www.alphaworks.ibm.com/tech/auiml)
and another who is a large mobile phone company I can't name.
All of these took the option to not start a separate JVM when the VE is
opened. The reason is because for their scenario they were happy
that the set of classes/widgets the user was going to drop from the palette
and compose with would be the same set of classes that were in the Eclipse
workbench itself. If this is the case you can start the Proxy subsystem
to recognize this and the startup time is faster. Is this the kind
of scenario you would be doing ?
Best regards,
Joe Winchester
Please respond to Discussions
people developing code for the Visual Editor project <ve-dev@xxxxxxxxxxx>
Sent by:
ve-dev-bounces@xxxxxxxxxxx
To:
<ve-dev@xxxxxxxxxxx>
cc:
Subject: [ve-dev]
VE with XML Persistence
Hy all,
we just evaluate the visual editor because we should build a specific editor
for designing visualisations (including widgets and draw2d figures). For
that purpose we want to use the visual editor generating xml instead of
java source code. The problem is that the visual editor is only contemplable
if we can improve the performance of the editor. The designing of a gui
should be fluently possible.
Has anyone experience with adapting the ve in this way?
Thanks in advance.
Regards,
Alexander Hoess
_______________________________________________
ve-dev mailing list
ve-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ve-dev
_______________________________________________
ve-dev mailing list
ve-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ve-dev
