activeX Geschwindigkeit

Nutzung, Komponenten, .NET

Moderator: Moderatoren

Antworten
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

activeX Geschwindigkeit

Beitrag von AUGE_OHR »

hi,

das activeX "langsam" ist weiss man ja, aber mit der Xbase++ activeX muss es ein "grösseres"
Problem geben.

Ich habe im M$ Mappoint Forum angefragt warum es bei 3000 Pushpin setzten 2 1/2Std bei mir
dauert ... und es liegt nicht an meinem Code.

nun bekam ich folgende Antwort:
Hi Jimmy,

I just did a test on a slower machine than yours. Putting 500 pushpins
on a map take here 36 seconds. So 3000 should take around 4 minutes. If
you do a win32 call to LockWindowsUpdate then the 500 pushpins take 10
seconds here.

So you have to examine your application to find out what it do during
the 2.5 hour! Since this is a very huge time you can eventually already
see what takes long if stepping with the debugger in it. It must be
something that takes almost 3 seconds! (of course it can be multiple
things together but you will find out soon)

--
rgds, Wilfried
Microsoft MapPoint MVP
es sollte also nur 4-5min dauert statt 2 1/2 Std WENN die activeX
Schnittstelle "so" arbeitet "wie es sein sollte". Es muss also bei Xbase++
einen massiven Overhead geben in solchen Situationen.

Nun fragt sich wie man das "gegen testen" könnte ... hat jemand schon mal
Vergleiche mit JazzAge oder YUKON und dem Xbase++ activeX gemacht ?
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: activeX Geschwindigkeit

Beitrag von AUGE_OHR »

moin,

nachdem man mir sagte das es "viel schneller" geht, hat mir das keine Ruhe gelassen und ich habe
ein "Minimum" Demo gemacht.

DBF 225 Records

a.) strip down Xbase++ Code to "minimum" using FindAddressResults()
and just use 1st Item oLocation := oResult:Item(1)

nComplet : 90.21
per Rec : 0.40

nSumFind : 0.14 -> FindAddressResults()
nSumGoto : 0.02 -> Goto(oLocation)
nSumAdd : 0.18 -> AddPushPin()

das seht ja schon völlig anderes aus. Dabei habe ich noch den Class Code übernommen ...

ich habe aber "alles raus" was nicht "unbedingt" notwendig ist und dazu gehört auch die "Logic".
Wenn FindAddressResults() z.b. mehrer findet werden die "gewichtet", während ich bei der Demo
immer das 1st nehme ... da sind schon mal paar Zehntel.

nun will ich es ja immer ganz genau wissen und habe versucht "noch was" rauszuholen, aber mit
Xbase++ war kaum noch was drin, also mal einen "anderen" Compiler versuchen :

nComplet : 22.95
per Rec : 0.10

nSumFind : 0.04
nSumGoto : 0.01
nSumAdd : 0.04
wrooom ... was für ein Unterschied ... :iroc:

und hier der Code

Code: Alles auswählen

PROCEDURE ShowMap(oWnd,oStatic)
LOCAL cLicCalendar := "Mappoint Control 9.0 Runtime License"
LOCAL cVer         := "11"
LOCAL nMode        := 1
LOCAL ClsCalendar  := "{8F78D7FC-BAE4-46A4-A79A-052356AB3DD4}"
*LOCAL ClsCalendar  := "MapPoint.Control"   +"."+ cVerCalendar
LOCAL oMapDlg
LOCAL aSize        :=  oStatic:currentsize()

*  oMapDlg := WvgActiveXControl():New( oWnd   , , {0,0}, aSize, , .t. )
   oMapDlg := WvgActiveXControl():New( oStatic, , {0,0}, aSize, , .t. )

   oMapDlg:CLSID   := ClsCalendar
   oMapDlg:license := cLicCalendar
   oMapDlg:Cargo   := "Mappoint"
   oMapDlg:create()

   oMapDlg:BorderStyle  := 1 // has border
   oMapDlg:Appearance   := 1 // border is 3D
   oMapDlg:NewMap( geoMapEurope )
   oMapDlg:Units := geoKm

   #IFDEF __XPP__
   #ELSE
*   oWnd:sendMessage( WM_SIZE, 0, 0 )
*   oWnd:Hide()
   #ENDIF
   oWnd:Show()

   China2Loc(oMapDlg)

RETURN

PROCEDURE China2Loc(oMap)
LOCAL cText
LOCAL cTelNo
LOCAL nCount := 0
LOCAL oLocation
LOCAL aLoc   := {}
LOCAL aSize := {400,300}
LOCAL aPos
LOCAL oPushPin := NIL
LOCAL nProz
LOCAL cProz
LOCAL nLen
LOCAL oResult
LOCAL cNeuNo
LOCAL nStart
LOCAL nStop
LOCAL nSumFind := 0
LOCAL nSumAdd  := 0
LOCAL nSumGoto := 0
LOCAL nComplet := 0
LOCAL nDiff
LOCAL imax

*LOCAL nLocXZahl
*LOCAL nLocYZahl
*LOCAL nLocXDec
*LOCAL nLocYDec

   SET ALTER TO HbAsiaMap.TXT
   SET ALTER ON

   oMap:Show()

   oMap:ActiveMap:ActiveRoute:Clear()

   SELECT 1
   USE (zPATH+"ASIA06.DBF") EXCLUSIVE
   nLen := LASTREC()
   GO TOP

   nComplet := SECONDS()
   DO WHILE !EOF()
      SELECT 1

      cTelNo := " 0"+ALLTRIM(ASIA06->VORWAHL)+"/"+ALLTRIM(ASIA06->TELEFON)
      cText  := TRIM(ASIA06->NAME)+CRLF+;
                TRIM(ASIA06->STRASSE)+CRLF+;
                ASIA06->PLZ+" "+ASIA06->ORT


      cNeuNo := "B"+STRZERO(RECNO(),4)
      REPLACE ASIA06->NeuNr WITH cNeuNo


      nStart   := SECONDS()
      oResult  := oMap:ActiveMap:FindAddressResults( ;
                                 TRIM(ConvToOEMCP(ASIA06->Strasse)),;
                                 TRIM(ConvToOEMCP(ASIA06->Ort    )),;
                                 NIL,;
                                 NIL,;
                                 TRIM(ConvToOEMCP(ASIA06->PLZ    )),;
                                 geoCountryGermany  )

      nStop    := SECONDS()
?     nDiff    := (nStop-nStart)
      nSumFind := nSumFind +nDiff

?     imax := oResult:Count()
      oLocation := oResult:Item(1) // just use 1st Item

      nStart   := SECONDS()
      oLocation:goto()
      nStop    := SECONDS()
?     nDiff    := (nStop-nStart)
      nSumGoto := nSumGoto +nDiff

      nStart   := SECONDS()
      oPushPin := oMap:ActiveMap:AddPushpin(oLocation,ASIA06->NeuNr )
      oPushPin:Symbol := 86
      oPushPin:Note   := cTelNo+CRLF+cText
      AADD(aLoc,oLocation)
      nStop    := SECONDS()
?     nDiff    := (nStop-nStart)
      nSumAdd  := nSumAdd +nDiff

? ""
      SELECT 1
      nCount++
      SKIP
*      IF nCount > 10
*         EXIT
*      ENDIF
   ENDDO

   IF LEN(aLoc) > 0
      oMap:ActiveMap:Union(aLoc):goto()
   ENDIF

   oMap:SaveMapAs("HbAsiaMap")

   ? "***************"
   ? ""
   ? "nComplet :"+STR( SECONDS()-nComplet        ,10,2)
   ? "per Rec  :"+STR((SECONDS()-nComplet)/nCount,10,2)
   ? ""
   ? "nSumFind :"+STR( nSumFind / nCount,10,2)
   ? "nSumGoto :"+STR( nSumGoto / nCount,10,2)
   ? "nSumAdd  :"+STR( nSumAdd  / nCount,10,2)
   ? ""

   SET ALTER OFF
   SET ALTER TO

RETURN
China2Loc() ist also in beiden Fällen, als Prozedure und Methode, der "selbe" Code.

man sieht es "ginge" wohl in 0.10sec pro Pushpin wenn ... :angryfire:

p.s. nicht wundern wenn da überall noch was von "Calendar" steht ... ;)
p.s.p.s. das "reine" Exe ist nur 836Kb gross ... wenn jemand sowas zum setzen von PushPins haben
möchte, dann bitte PN an mich da ich die DbStruct() dafür benötige.
gruss by OHR
Jimmy
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: activeX Geschwindigkeit

Beitrag von brandelh »

Hi,

ich hatte vor kurzem einen Test mit PowerBasic und Excel Arbeitsblat "jede Zelle einzeln füllen" durchgeführt.
Aus dem Gedächtnis war PowerBasic 10x so schnell wie Xbase++. Allerdings kann ich bei Xbase++ ein
Array komplett übergeben, dann ist es nicht so tragisch.

Aus meiner Sicht müsste man (wenn man es denn wirklich braucht ;-) ) in einer besser geeigneten
Sprache die man kann (C/c++ ? ) die ActiveX Zugriffe programmieren und eine DLL erstellen, die aus Xbase++
mit DLL Zugriffen gesteuert wird. Oder man kauft sich eine LIB die das besser macht.

Die von Hannes scheint da einiges mehr zu bieten, allerdings habe ich keine Speed Tests damit gemacht.
Gruß
Hubert
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: activeX Geschwindigkeit

Beitrag von AUGE_OHR »

hi,

ich wundere mich doch ein wenig das sich bei über 400% (!!!) nur einer dafür "interessiert" ...

nun gilt das ja nicht nur für activeX, sondern auch für Xbase++ "selbst", den wenn man mal die
Zeiten zusammenaddiert "fehlt" doch noch was. bei den 0.40sec gehen 0.06 für Xbase++ drauf,
während der "andere" nur 0.01 braucht, also 600 % (!!!) ... und das bei den paar Zeilen.

ich "denke" das die Zeit bei den DBF Operationen verloren geht und das obwohl ich ja EXCLUSIV
verwende, aber ein REPLACE ...

ich ich muss es nochmals erwähnen : immer mit dem "selben" Source Code aber verschiedene Compiler
gruss by OHR
Jimmy
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: activeX Geschwindigkeit

Beitrag von Jan »

Jimmy,

erwartest Du jetzt, daß alle knapp 300 Forenteilnehmer hier ihren Kommentar zu schreiben und Deine Messungen bestätigen? Oder sich mit Dir über die Langsamkeit aufregen?

Nur weil keiner was am Wochenende dazu schreibt heißt das doch nicht, daß keinen das interessiert. Wobei es sicher so einige hier gibt, die das in der Tat nicht die Bohne interessiert.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: activeX Geschwindigkeit

Beitrag von AUGE_OHR »

hi,
Jan hat geschrieben:Wobei es sicher so einige hier gibt, die das in der Tat nicht die Bohne interessiert
sicherlich gibt es viele die "nur lesen", aber das Thema "Geschwindigkeit" wird sicherlich alle interessieren.

wir wissen ja alle das Xbase++ nicht gerade die schnellste Sprache ist, aber eines haben ja alle
Xbase (ohne ++) gemeinsam : Die Sprache und Befehle.

somit ist es also durchaus möglich "Vergleiche" zwischen Xbase (ohne ++) Sprachen zu machen.

Ich bin nun durch Zufall (und viel Arbeit) darauf gestossen das "irgendwas" nicht stimmen kann.
Ich habe ja Mappoint nicht erst seit gestern in Betrieb und damit die ganze Zeit "gelebt" das es
so langsam ist ... naja dachte ich, ist eben Xbase.

Ich habe also nicht "über den Horizont" gesehen und war recht "zufrieden" mit meinem Code bis
man mir sagte dass es doch 100x schneller geht ... Hallo aufwachen !!!

... man "erzählt" uns das die "Hardware" Performance, trotz besserer Hardware, abgenommen
hätte ... und was ist mit der Software ? ist "alte" Software auf neuer Hardware "langsamer" als
"neue" Software ? was ist mit "Anpassung" ?

und genau darauf will ich raus : Xbase++ ist mit jeder Version "langsamer" geworden.

Auch das "Werkzeug" das wir benutzen wird selten in Frage gestellt obwohl dieses ja unseren "Wirkungskreis" beschränkt.

also wenn das keine "juckt" dann weiss ich auch nicht mehr weiter. und wenn wir dagegen nicht
was "unternehmen" wird die Tendenz weiter in der Richtung gehen (siehe Ownerdraw ... langsam)

Der "Witz" dabei scheint aber das man uns das für "Neu" verkauft und wie toll das doch alles ist
und die meisten scheinen das auch zu glauben ohne es selbst zu "testen". (100x Ownerdraw
gegen normale Buttons)

genau dieses "in-Frage" stellen und "testen" war nun meine Frage und ich wüsste gerne eure
Meinung ob das Thema "Geschwindigkeit" für euch relevant ist und ob ihr selbst in dieser Richtung
"getestet" habt.
gruss by OHR
Jimmy
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: activeX Geschwindigkeit

Beitrag von brandelh »

AUGE_OHR hat geschrieben: ... man "erzählt" uns das die "Hardware" Performance, trotz besserer Hardware, abgenommen
hätte ... und was ist mit der Software ? ist "alte" Software auf neuer Hardware "langsamer" als
"neue" Software ? was ist mit "Anpassung" ?
ich weiß zwar nicht, was "jemand erzählt" hat, aber meine Programme laufen auf neuen
Rechnern schneller als auf alten ! (solange man den Prozess auf einen Prozessor beschränkt ;-) )

Allerdings wäre ich früher nie auf die Idee gekommen ActiveX einzusetzen (es ging ja sowieso nicht).
Also NEUE Funktionen mit anderen Compilern zu vergleichen ist legitim (das mache ich ja auch ab und zu),
aber daraus zu schließen, dass es auf alten Rechnern schneller laufen würde ist doch ... :?:

Was sicher stimmt ist, dass unsere Programme (Datenbankanwendungen) nicht so von der neuen
Hardware profitieren, wie wir das gerne hätten, aber ein simples Eingabefeld ist halt kaum zu beschleunigen.
Dass DBF Dateien von Microsoft im shared Modus benachteiligt werden, das haben wir schon gehört,
das hat ja aber nichts mit Hardware zu tun oder ?
Auch die Aussage, dass moderne Festplatten länger brauchen als alte (so aus dem Gedächtnis) ist
so natürlich falsch ! ALLES was man auf einer neuen SATA Platte macht ist schneller als auf einer alten PATA (älter als 2 Jahre).
NUR wenn ich sage, das eine 2 GB Platte die 2 GB schneller liefern konnte, als eine 2 TB Platte die 2 TB,
dann stimmt dies, aber ist das wirklich ein Vergleich der für "langsame Hardware" genutzt werden kann ?

Das Einzige was man daraus folgern kann, ist, dass die Hardware nicht so schnell schneller werden konnte, als
unsere Ansprüche/Datenmengen gestiegen sind ... mal ehrlich, wer hat solche DBFs ?
Meine Größte bewegt sich um die 400 MB und aktuell geht nicht mehr als 2 GB je DBF - das war schon immer so !

ActiveX ist per se langsam !
In Verbindung mit Xbase++ erst recht, ... solange man nicht tricksen kann (komplettes Array auf einmal übergeben).
Allerdings geht das mit dem Tricksen recht oft ... :D
Gruß
Hubert
Benutzeravatar
Martin Altmann
Foren-Administrator
Foren-Administrator
Beiträge: 16502
Registriert: Fr, 23. Sep 2005 4:58
Wohnort: Berlin
Hat sich bedankt: 111 Mal
Danksagung erhalten: 48 Mal
Kontaktdaten:

Re: activeX Geschwindigkeit

Beitrag von Martin Altmann »

Hmmm,
ich habe mir beim Duschen gerade überlegt, dass dies ja eigentlich ein klassisches Beispiel für den Einsatz von Multithreading wäre:
Zehn Threads greifen sich jeweils einen Punkt, berechnen alles zur Darstellung notwendige und geben dann an den 11. Thread (der das Darstellen in MapPoint regelt) die Daten weiter.
Dann wird ein neuer Punkt genommen und berechnet, bis alle durch sind.
Dadurch sollte einiges an Geschwindigkeitsgewinn drin sein.
Nur leider - wenn ich mich recht erinnere - ist die Xbase++-ActiveX-Implementation wohl nicht Threadfähig - zumindest meine ich, das irgendwann mal irgendwo gelesen gehabt zu haben.
Einfach mal in die Richtung probieren.

Viele Grüße,
Martin
:grommit:
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/

Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: activeX Geschwindigkeit

Beitrag von AUGE_OHR »

Martin Altmann hat geschrieben:Hmmm,
ich habe mir beim Duschen gerade überlegt, dass dies ja eigentlich ein klassisches Beispiel für den Einsatz von Multithreading wäre:
Zehn Threads greifen sich jeweils einen Punkt, berechnen alles zur Darstellung notwendige und geben dann an den 11. Thread (der das Darstellen in MapPoint regelt) die Daten weiter.
Dann wird ein neuer Punkt genommen und berechnet, bis alle durch sind.
Dadurch sollte einiges an Geschwindigkeitsgewinn drin sein.
Nur leider - wenn ich mich recht erinnere - ist die Xbase++-ActiveX-Implementation wohl nicht Threadfähig - zumindest meine ich, das irgendwann mal irgendwo gelesen gehabt zu haben.
Einfach mal in die Richtung probieren.
nur mal theoretisch : für jeden Punkt starte ich einen eigenen Thread, also 300 Threads ...

Quizfrage : wäre es (wesentlich) "schneller" als 300 "for-next" ?

ich denke Nein, den in "Wirklichkeit" wird ja alles "hintereinander" ausgeführt. Es wird also immer
nur zum nächsten Thread weiter-geschaltet "wenn Zeit" für den Thread "ansteht", also er "an
der Reihe" ist.

Ich denke das Threads nur was bringen würden "wenn Zeit" vorhanden ist damit man es "im
Hintergrund" laufen lassen könnte

wenn ist aber richtig verstanden habe, ist trotz Gigaherz Wahnsinn, das "minimum an Zeit" nicht
verändert worden d.h. die Application kann "nicht schnell" reagieren da jeder "Zeit Abschnitt" ja
durchlaufen werden muss ... ist das der Grund warum man "nur" bis 4GHz beim "Übertackten" kommt ?

***

ich habe nun auch "bewusst" die ActiveX genommen für "Vergleiche", den ich wollte nun nicht
mit DBF "Benchmark" anfangen ... exclusive/share , Op´s locking etc wollte ich vermeiden.

bei den activeX "denke" ich nun das ja "alle das selbe" Problem haben sollten, auf API zugreifen
Daten "konvertieren" und "übergeben" und das ganze "verwalten" ... das "sollte" doch auch für
verschiedene "Sprachen" ein ähnliches Ergebniss geben ?

***

Es ist bekannt das Xbase++ manchmal "mehr" macht ... Beispiel NationMsg() statt GetLocaleInfo()
und das alles "kostet" Zeit. Ich frage mich ob bei activeX sowass auch passiert und man das
"abschalten" kann ...

Frage : was ist macht ":UseGuiThread := .F." und was ist ":Mashalling"
gruss by OHR
Jimmy
Benutzeravatar
Martin Altmann
Foren-Administrator
Foren-Administrator
Beiträge: 16502
Registriert: Fr, 23. Sep 2005 4:58
Wohnort: Berlin
Hat sich bedankt: 111 Mal
Danksagung erhalten: 48 Mal
Kontaktdaten:

Re: activeX Geschwindigkeit

Beitrag von Martin Altmann »

Hallo Jimmy,
nein - 300 Threads geht auf keinen Fall! Da schmiert Windows vorher ab!
Darum meinte ich ja, 10 Threads (oder auch 20), die sich jeweils einen Punkt vornehmen. Wenn alles berechnet ist, kümmert sich MapPoint um die Anzeige (die ja auch eine Weile dauert), während bereits der nächste Punkt berechnet wird.
Im Moment machst Du das ja "stur" nacheinander - erst, wenn ein Punkt angezeigt ist, wird der nächste berechnet...
Marshalling bedeutet, das Übergeben von "Daten" von einem Programm an ein anderes - in dem Fall halt von Xbase++ an einen ActiveX-Control. Etwas ausführlicher: http://de.wikipedia.org/wiki/Marshalling oder auch hier: http://msdn.microsoft.com/de-de/magazine/cc164193.aspx

Ansonsten habe ich in der activeX-Newsgroup von Alaska in einem Posting von James Loughner die folgenden Hinweise gefunden:

:UseGUIThread := .f. verhindert, dass das ActiveX-Control mit dem EVM interagiert.
:UserEvents := .f. sorgt dafür, dass Events innerhalb des Threads bleiben.
AutoTranslateColor() kann man nutzen, falls Farben bei einem ActiveX-Control falsch angezeigt werden.

Viele Grüße,
Martin
:grommit:
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/

Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: activeX Geschwindigkeit

Beitrag von AUGE_OHR »

Martin Altmann hat geschrieben:nein - 300 Threads geht auf keinen Fall! Da schmiert Windows vorher ab!
:)
Martin Altmann hat geschrieben: Darum meinte ich ja, 10 Threads (oder auch 20), die sich jeweils einen Punkt vornehmen. Wenn alles berechnet ist, kümmert sich MapPoint um die Anzeige (die ja auch eine Weile dauert), während bereits der nächste Punkt berechnet wird.
Im Moment machst Du das ja "stur" nacheinander - erst, wenn ein Punkt angezeigt ist, wird der nächste berechnet...
sorry, aber die Methode :FindAddressResults() macht das alles d.h. in diesen Demo gibt es keine "Berechnungen" (mal vom Sum abgesehen)

die Grund Idee habe ich schon verstanden, nur ich "denke" das bei 100% Auslastung hier
Threads nicht bringen "würden" ... ich werde es aber trotzdem mal "testen"
Martin Altmann hat geschrieben: Marshalling bedeutet, das Übergeben von "Daten" von einem Programm an ein anderes - in dem Fall halt von Xbase++ an einen ActiveX-Control. Etwas ausführlicher: http://de.wikipedia.org/wiki/Marshalling oder auch hier: http://msdn.microsoft.com/de-de/magazine/cc164193.aspx
ok, danke für die URL, ich werde mir die man durchlesen
Martin Altmann hat geschrieben: Ansonsten habe ich in der activeX-Newsgroup von Alaska in einem Posting von James Loughner die folgenden Hinweise gefunden:
danke für die Mühe
:UseGUIThread := .f. verhindert, dass das ActiveX-Control mit dem EVM interagiert
hm ... das könnte noch paar hundertstel bringen ... mal ausprobieren
gruss by OHR
Jimmy
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: activeX Geschwindigkeit

Beitrag von Tom »

Ich habe auch eine Gegenüberstellung laufen lassen. Meine App generiert eine Kundenübersicht, zeigt also auf einer Karte an, wo die Kunden (Patienten) wohnen. Auf meinem schnellsten Rechner mit knapp hundert Adressen dauert das fast zwei Minuten. Ein Kumpel, der mit VB programmiert, hat das nachgestellt, mit den gleichen Adressen und auf einem langsameren Rechner. Es dauert zwanzig Sekunden. Nach der Erzeugung des Controls und dem ersten FindAdress() füllt sich der Bildschirm in Windeseile mit Pushpins.

Edit: Mein Beispiel arbeitet mit einem Adressarray. Datenbankzugriffe finden im gemessenen Control nicht statt.
Herzlich,
Tom
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: activeX Geschwindigkeit

Beitrag von Jan »

Hat denn jemand das mal ausprobiert mit dem ursprünglichen 1.9? Ist das ein Problem von SL1 oder grundsätzlich Xbase++?

Ich frage deswegen weil ich vor einiger Zeit ja mal ein Thema aufgemacht habe, da mit dem SL1 das Arbeiten mit pdf und dem Reader geschwindigkeitsmäßig eine Qual ist. Unter original 1.9 lief das aber ganz ordentlich.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: activeX Geschwindigkeit

Beitrag von Tom »

@Jan: Ich kann an dieser Stelle keine signifikanten Unterschiede zwischen 1.9 und SL1 feststellen. Ich teste das aber im Laufe des Tages nochmal intensiver.
Herzlich,
Tom
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: activeX Geschwindigkeit

Beitrag von brandelh »

Hi,

ich sag doch, wir brauchen eine Vermittlersprache ;-)

allerdings habe ich weder Mappoint, noch Zeit, sonst würde ich es mal mit PowerBasic versuchen.
Gruß
Hubert
Benutzeravatar
Wolfgang Ciriack
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2932
Registriert: Sa, 24. Sep 2005 9:37
Wohnort: Berlin
Hat sich bedankt: 13 Mal
Danksagung erhalten: 34 Mal
Kontaktdaten:

Re: activeX Geschwindigkeit

Beitrag von Wolfgang Ciriack »

Also ich kann das nicht bestätigen.
Bei mir werden 30 Adressen in ca. 5 Sekunden, 339 Adressen in ca. 30 Sek. angezeigt (Mappoint 2006, Xbase++ 331)
Viele Grüße
Wolfgang
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: activeX Geschwindigkeit

Beitrag von AUGE_OHR »

Wolfgang Ciriack hat geschrieben:Also ich kann das nicht bestätigen.
Bei mir werden 30 Adressen in ca. 5 Sekunden, 339 Adressen in ca. 30 Sek. angezeigt (Mappoint 2006, Xbase++ 331)
witzig, dann muss bei dir "irgendwas" anders sein als bei mir ...

zur v331 vs v355 activeX : Ich "meine" das die v355 "anders" ist, da mein Bild und :SetCaption()
mit der v355 "mehr synchron" läuft d.h. nach dem :SetCaption kommt auch "das" Bild.

bei der v331 war :setCaption schneller da, aber manchmal "so schnell" das ich den "Map-Server"
"verloren" habe ... dann musste ich auf "wiederholen" clicken um "das" Bild zu bekommen.

@Jan : das mit dem PDF kann ich nur für Version > 6 bestätigen. Die v6.x ist bei mir "schnell"

@Hubert : "Vermittlersprache" ... ich werde mal suchen was man sonst als activeX ausprobieren könnte.
gruss by OHR
Jimmy
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: activeX Geschwindigkeit

Beitrag von brandelh »

AUGE_OHR hat geschrieben:@Hubert : "Vermittlersprache" ... ich werde mal suchen was man sonst als activeX ausprobieren könnte.
ich meinte damit, dass man eine DLL oder EXE erstellt mit dem compiler den man halt kennt,
solange das erzeugte Hilfsprogramm schneller ist als Xbase++ und dann von Xbase++ Programmen
auf dieses Zwischentool zugreift.
Gruß
Hubert
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: activeX Geschwindigkeit

Beitrag von AUGE_OHR »

brandelh hat geschrieben:
AUGE_OHR hat geschrieben:@Hubert : "Vermittlersprache" ... ich werde mal suchen was man sonst als activeX ausprobieren könnte.
ich meinte damit, dass man eine DLL oder EXE erstellt mit dem compiler den man halt kennt,
solange das erzeugte Hilfsprogramm schneller ist als Xbase++ und dann von Xbase++ Programmen
auf dieses Zwischentool zugreift.
JA genau daran arbeite ich (auch)

ich habe hier eine modifizerte XppOLE Version von Hector (Pezoa Gonzalez?) wo einige C-Routinen von Pablo Botella sind.
Ich habe mal paar Test damit gemacht und die Office OLE funktionieren erstaunlich gut und "schnell" ...

dann hab ich es mit Mappoint probiert und da hat XppOLE "versagt" ... aber es ist ja auch nicht dafür "angepasst" von Pablo ...

Das brauchte mich auf die Idee ihn mal direkt auf das Thema "other Comiler" DLL anzusprechen
und er sagte "kein Problem" da ich KEINE Datenübergabe (Marshal) und KEINEN Return Wert (Moniker) benötige.

Er geht von 2-3Std aus wenn er es für mich "anpassen" soll ... also alles "im Rahmen machbar".

nun muss ich aber "aufpassen" welche activeX den wirklich "notwendig" sind, also z.b. Echtzeit activeX Sachen und so,
den "jedes" müsste "angepasst" werden ;)
gruss by OHR
Jimmy
Antworten