🚀 go-pugleaf

Użytkownik "Ciekawy" <ciekawy32@gmail.com> napisał w wiadomości 
news:lmmlcm$6ub$1@node1.news.atman.pl...
> Witam
>
> Szukałem możliwości poprawienia wydajności w tym celu zmieniłem dostęp do 
> danych z ZEOS na UNIDac.
> Pytnie dotyczy danych geometrycznych z tabeli zawierającej 25000 rekordów 
> Oracle (sdo_gometry)
> Przy użyciu ZEOS mapa w oparciu o te dane generowana była w ciągu
> 1 min i 35 sek
> Po zmianie na UNIDAc ten sam algorytm, to samo zapytanie powoduje, że
> mapa generowana jest w ciągu 25 sek.
> Nie kupiłem jeszcze UniDaca zastanawiam się czy może inna biblioteka, dała by 
> mi lepsze rezultaty. Wiem, że mam jeszcze trochę do poprawy, bo darmowy 
> program QuantumGis generuje identyczną mapę w ciągu 19 sek.
> Być może poprawa algorytmów rysowania, być dostęp do danych, a być może to że 
> cały mój program zakłada dostęp do danych z LittleEndian, a oracle
> daje mi dane w BigEndian i muszę każdą daną dla  punktów "obracać".
> BTW czy ma ktoś kod w ASM do obrócenia typu dooble? Bo ja robię to w paskalu.
> Proszę o sugestie
>
Pokaż SQL-e a nie odrazu zmiana DAO. 

> Pokaż SQL-e a nie odrazu zmiana DAO.
Jeżeli SQL-e są dobre to może w ogóle pomiń komponenty i ciągnij dane 
bezpośrednio biblioteką Front-End. 

W dniu 2014-06-04 10:59, konsul41@wp.pl pisze:
>> Pokaż SQL-e a nie odrazu zmiana DAO.
> Jeżeli SQL-e są dobre to może w ogóle pomiń komponenty i ciągnij dane
> bezpośrednio biblioteką Front-End.

SELECT ('Pole geometryczne ').GET_WKB() as WKBStream  FROM 
tabela_zawierająca_Geometrię  WHERE SDO_ANYINTERACT -
//funkcja selekcjonująca obiekty geometryczne mieszczące się w ramce 
//mapy w zależności od zooma

Tu są parametry dla funkcji SDO_ANYINTERACT
(Pole geometryczne , SDO_GEOMETRY(2003,%s , NULL, 
SDO_ELEM_INFO_ARRAY(1,1003,3),'+'SDO_ORDINATE_ARRAY(%f,%f, %f,%f))) = %s')

SDO_ORDINATE_ARRAY - to tablica współrzędnych kwadratu który właśnie 
oglądam stęd do generowania mapy są mi potrzebne tylko obiekty 
znajdujące się w środku. %f,%f, %f,%f - to tablica zawierająca 
współrzędnerzędne ograniczające.

Nie pisałem pytania bo i dla ZEOSA i dla UniDaca jest ono identyczne
W zeosie wykorzystywałem TZquery w unidaku TUniQuery



---
Ta wiadomość e-mail jest wolna od wirusów i złośliwego oprogramowania, ponieważ ochrona avast! Antivirus jest aktywna.
http://www.avast.com

> SDO_ORDINATE_ARRAY - to tablica współrzędnych kwadratu który właśnie oglądam 
> stęd do generowania mapy są mi potrzebne tylko obiekty znajdujące się w 
> środku. %f,%f, %f,%f - to tablica zawierająca współrzędnerzędne ograniczające.
>
Pokaż indeksy (skrypt tworzący tabelę)
Tutaj może niech się wypowiedzą specjaliści od SQL.

Jeżeli to nie jest problem związany z SQL to żeby przyśpieszyć pozostaje Ci 
pominięcie komponentów bazodanowych(dość duzy balast) i bezpośrednie operacje na 
dll Oracla(klient). W postgresie jest to nawet dość proste, a jak jest Oracl to 
nie wiem. 

W dniu 2014-06-04 10:29, Ciekawy pisze:
> Witam
>
> Szukałem możliwości poprawienia wydajności w tym celu zmieniłem dostęp
> do danych z ZEOS na UNIDac.
> Pytnie dotyczy danych geometrycznych z tabeli zawierającej 25000
> rekordów Oracle (sdo_gometry)
> Przy użyciu ZEOS mapa w oparciu o te dane generowana była w ciągu
> 1 min i 35 sek

Którego ZEOS-a wykorzystujesz?
Bo 7.2 z bieżącymi aktualizacjami:
http://svn.code.sf.net/p/zeoslib/code-0/branches/testing-7.2/
powinien być szybszy(od 7.1.13a) szczególnie właśnie dla ORACLE.

miab

> Jeżeli to nie jest problem związany z SQL to żeby przyśpieszyć pozostaje
> Ci pominięcie komponentów bazodanowych(dość duzy balast) i bezpośrednie
> operacje na dll Oracla(klient). W postgresie jest to nawet dość proste,
> a jak jest Oracl to nie wiem.

tak zrobić nie mogę przepisanie, aplikacji aby ją testować na innym DAC
który zawiera komponent po TDataSet, albo coś w rodzaju TIBSQL z ibx to 
dla mnie dzień roboty, natomiast praca bezpośrednio na dll to masakra, 
której się nie podejmę. Szukam raczej szybszego DAC przepiszę potestuję 
i pewnie kupię. Co do zapytania SQL i tabeli, to nie ma się do czego 
przyczepić. (pracuję przy tym od pewnego czasu) i wydaje mi się, że jest 
na tyle banalne, że tu się nic nie zrobi. Można jeszcze je poprawić aby 
obiekty które małe powierzchniowo były pominięte, ale to ciągnie za sobą 
konsekwencje.

---
Ta wiadomość e-mail jest wolna od wirusów i złośliwego oprogramowania, ponieważ ochrona avast! Antivirus jest aktywna.
http://www.avast.com

W
> Którego ZEOS-a wykorzystujesz?
> Bo 7.2 z bieżącymi aktualizacjami:
> http://svn.code.sf.net/p/zeoslib/code-0/branches/testing-7.2/
> powinien być szybszy(od 7.1.13a) szczególnie właśnie dla ORACLE.
>
> miab
>
właśnie go instaluję, bo miałem wcześniejszą wersję. Na postgresie 
wszystko działało mi bez zarzutu, może poza dziwnym krzyczeniem o
o libpq.dll pomimo tego, że miał podaną ścieżkę. W różnych dziwnych 
sytuacjach.

Pozdrawiam Ciekawy

---
Ta wiadomość e-mail jest wolna od wirusów i złośliwego oprogramowania, ponieważ ochrona avast! Antivirus jest aktywna.
http://www.avast.com

W dniu 2014-06-04 12:26, Ciekawy pisze:
> W
>> Którego ZEOS-a wykorzystujesz?
>> Bo 7.2 z bieżącymi aktualizacjami:
>> http://svn.code.sf.net/p/zeoslib/code-0/branches/testing-7.2/
>> powinien być szybszy(od 7.1.13a) szczególnie właśnie dla ORACLE.
>>
>> miab
>>
> właśnie go instaluję, bo miałem wcześniejszą wersję. Na postgresie
> wszystko działało mi bez zarzutu, może poza dziwnym krzyczeniem o
> o libpq.dll pomimo tego, że miał podaną ścieżkę. W różnych dziwnych
> sytuacjach.

Dziwna sytuacja to jest pewnie wtedy jak IDE Delphi nie widzi biblioteki.
Dlatego ja zawsze w środowisku deweloperskim umieszczam odpowiednie 
biblioteki linkowane dynamicznie tak żeby je Delphi bez problemów widziało.

miab

> Dziwna sytuacja to jest pewnie wtedy jak IDE Delphi nie widzi biblioteki.
> Dlatego ja zawsze w środowisku deweloperskim umieszczam odpowiednie
> biblioteki linkowane dynamicznie tak żeby je Delphi bez problemów widziało.
>
> miab
>
Nowa wersja zeszła z zapytaniem testowym do 1 min i 25 sek.

---
Ta wiadomość e-mail jest wolna od wirusów i złośliwego oprogramowania, ponieważ ochrona avast! Antivirus jest aktywna.
http://www.avast.com

W dniu 2014-06-04 12:54, Ciekawy pisze:
>
>> Dziwna sytuacja to jest pewnie wtedy jak IDE Delphi nie widzi biblioteki.
>> Dlatego ja zawsze w środowisku deweloperskim umieszczam odpowiednie
>> biblioteki linkowane dynamicznie tak żeby je Delphi bez problemów
>> widziało.
>>
>> miab
>>
> Nowa wersja zeszła z zapytaniem testowym do 1 min i 25 sek.
Ciekawe... pokaż kod, który przygotowuje komponety Query, odpala 
zapytanie i iteruje po DataSecie.

Ile trwa samo pobranie i przetwarzanie danych na warstwie DAC (dla ZEIS 
i UniDAC) bez ich przetwarzania w mapę?

-- 
wloochacz

> Ile trwa samo pobranie i przetwarzanie danych na warstwie DAC (dla ZEIS
> i UniDAC) bez ich przetwarzania w mapę?
>

13:57:25 start
13:58:40 koniec
Czyli 1 minuta i 15 sekund bez rysowania mapy dla zeosa przy zapytaniu typu:
Select (geom).get_wkb() from budynki
test polegał na zwykłym przejściu pętli po TZQuery:

Memo1.Lines.Add(TimeToStr(time));
ZQuery1.Open;
ZQuery1.First;
while not zquery1.Eof do  ZQuery1.Next;
Memo1.Lines.Add(TimeToStr(time));

Co do kodu pobierania danych do rysowania to mam go rozrzuconego po 
wielu modułach, ale w tym przypadku przerysowanie mapy to 1 minuta 25
sek nawigowanie po danych zaś 1 minuta 15. Stąd samo rysowanie zajmuje 
mi 10 sek, problemem jest dostęp do danych.
A w zasadzie dostęp do funkcji get_wkb obiektu graficznego.
Przy tej samej tabeli kiedy pytam o dane tradycyjne, dostęp (pętla) po 
całej tabeli to sekundy.

Pozdrawiam Ciekawy



---
Ta wiadomość e-mail jest wolna od wirusów i złośliwego oprogramowania, ponieważ ochrona avast! Antivirus jest aktywna.
http://www.avast.com

W dniu 2014-06-04 14:14, Ciekawy pisze:
>
>> Ile trwa samo pobranie i przetwarzanie danych na warstwie DAC (dla ZEIS
>> i UniDAC) bez ich przetwarzania w mapę?
>>
>
> 13:57:25 start
> 13:58:40 koniec
> Czyli 1 minuta i 15 sekund bez rysowania mapy dla zeosa przy zapytaniu
> typu:
> Select (geom).get_wkb() from budynki
> test polegał na zwykłym przejściu pętli po TZQuery:
Ale wiesz - są takie patenty, jak FetchAll, DisableControls, 
ForwardOnly, itp.
to wszystko ma wpływ na wydajność działania i pobierania danych przez 
dany TDataSet.
Poza tym, jedne komponenty coś tam mają a inne niekoniecznie...
Może sa jakieś myki dla ZEOS, które pozwolą wycisnąć więcej.
Pytanie tylko - gdzie jest wąskie gardło.
Moim zdaniem chyba nie w pobieraniu danych bo ich nie ma aż tak dużo, 
żeby to tyle trwała - no chyba, że to (geom).get_wkb() zabija skutecznie 
wydajność po stronie serwera...
No więc właśnie gdzie jest wąskie gardło?

> Memo1.Lines.Add(TimeToStr(time));
> ZQuery1.Open;
> ZQuery1.First;
> while not zquery1.Eof do  ZQuery1.Next;
> Memo1.Lines.Add(TimeToStr(time));
>
> Co do kodu pobierania danych do rysowania to mam go rozrzuconego po
> wielu modułach,
A to może być kluczowe.
Pobieranie danych porozrzucane po wielu modułach - dlaczego tak, z 
ciekawości?

> ale w tym przypadku przerysowanie mapy to 1 minuta 25
> sek nawigowanie po danych zaś 1 minuta 15. Stąd samo rysowanie zajmuje
> mi 10 sek, problemem jest dostęp do danych.
To niemożliwe, tyle czasu dla tak małej ilości danych??
Te datasety są podłączone do jakiś kontrolek przez TDataSeource?
Jeśli tak - to dlaczego tam nie ma ZQuery1.DisableControls?

> A w zasadzie dostęp do funkcji get_wkb obiektu graficznego.
> Przy tej samej tabeli kiedy pytam o dane tradycyjne, dostęp (pętla) po
> całej tabeli to sekundy.
No więc właśnie - a co to jest za typ danych z tej funkcji get_wkb?
I ile czasu trwa wykonanie identycznego zapytania  a tym samym 
komputerze, ale z wykorzystaniem standardowych narzędzi bazy danych?

-- 
wloochacz

W dniu 2014-06-04 15:41, wloochacz pisze:

> Moim zdaniem chyba nie w pobieraniu danych bo ich nie ma aż tak dużo,
> żeby to tyle trwała - no chyba, że to (geom).get_wkb() zabija skutecznie
> wydajność po stronie serwera...
> No więc właśnie gdzie jest wąskie gardło?
Ten test który teraz podesłałem to był "czysty" komponent nie połączony 
z żadnymi kontrolkami. Czy zwykłe pobranie danych i "przejście" pętlą po 
wszystkich rekordach.


>>
>> Co do kodu pobierania danych do rysowania to mam go rozrzuconego po
>> wielu modułach,
> A to może być kluczowe.
> Pobieranie danych porozrzucane po wielu modułach - dlaczego tak, z
> ciekawości?

Sprawy historyczne najpierw pisałem pod zwykłe pliki, potem 
rozbudowywałem hierarchię pod
czytanie z baz danych, stąd na zasadzie polimorfizmu program wchodzi w 
te moduły które są odpowiednie dla danego typu. Ale napisałem bzdeta 
wcześniej w zasadzie pobieranie danych jest w jednym miejscu. Na zasadzie

1 Pobierz wszystkie geometrie spełniające warunek (będące w granicach 
ekranu)

Petla
Przerysuj wszystkie geometrie /tu wchodzi w różne moduły w zależności od 
typu/
next;

Tylko, że o ile proces pobierania danych wraz z rysowaniem trwa 1 min 25
to samo pobieranie danych "czyste" 1 minuta 15. Stąd mój wniosek, że coś 
jest nie tak z pobieraniem danych. Zresztą duże programy komercyjne i 
niekomercyjne rysują tą samą mapę od 17 do 19 sekund. Kiedy korzystałem 
z UNIDACA mój robił to w 25 sek.


> No więc właśnie - a co to jest za typ danych z tej funkcji get_wkb?
W zasadzie to BLOB

FUNCTION MDSYS.OGC_AsBinary  (
   g ST_Geometry)
     RETURN BLOB IS
BEGIN
   RETURN g.GET_WKB();
END OGC_AsBinary;

Teraz testuję dbExpresa z Devarta i chciałbym firedac, ale chyba zgodnie 
z polityką marketingową embrr, nie mogę pobrać żadnego triala, tylko 
instalować sobie całe Delphi w trialu czy się mylę??

Pozdrawiam Ciekawy


---
Ta wiadomość e-mail jest wolna od wirusów i złośliwego oprogramowania, ponieważ ochrona avast! Antivirus jest aktywna.
http://www.avast.com

On Wed, 04 Jun 2014 12:14:24 +0200, Ciekawy <ciekawy32@gmail.com>
wrote:


>tak zrobić nie mogę przepisanie, aplikacji aby ją testować na innym DAC
>który zawiera komponent po TDataSet, albo coś w rodzaju TIBSQL z ibx to 
>dla mnie dzień roboty, natomiast praca bezpośrednio na dll to masakra, 

Prawdopodobnie tutaj masz problem
ADODataSet.DisableControls

Pisałem już kiedyś o tym
zob. pl.comp.lang.java   JDBC vs. PHP (ORACLE)

P.




---
Ta wiadomość e-mail jest wolna od wirusów i złośliwego oprogramowania, ponieważ ochrona avast! Antivirus jest aktywna.
http://www.avast.com

W dniu 2014-06-04 12:54, Ciekawy pisze:
>
>> Dziwna sytuacja to jest pewnie wtedy jak IDE Delphi nie widzi biblioteki.
>> Dlatego ja zawsze w środowisku deweloperskim umieszczam odpowiednie
>> biblioteki linkowane dynamicznie tak żeby je Delphi bez problemów
>> widziało.
>>
>> miab
>>
> Nowa wersja zeszła z zapytaniem testowym do 1 min i 25 sek.

A zobacz W ZQuery Options-doCachedLobs na True i jeszcze FetchRow więcej 
niż zaczytujesz.

miab

>> Nowa wersja zeszła z zapytaniem testowym do 1 min i 25 sek.
>
> A zobacz W ZQuery Options-doCachedLobs na True i jeszcze FetchRow więcej
> niż zaczytujesz.
>
> miab
>
Niestety UniDac również, jest nie do przyjęcia po zapytaniu i zamknięciu 
datasetu zwalnia bardzo długo pamięć blokując program.
Jedyne wyjście to przeniesienie funkcji, Get_WKB() na klienta.
Będę miał prośbę o naukę do kolegów jutro, bo słabo stoję z Oraclem a 
jeszcze słabiej z możliwościami poszczególnych DAO.
Odczyt współrzędnych z obiektu to co jest mi tak na prawdę potrzebne
trwa mniej jedna sekunda dla 22000 obiektów, problem polega na tym,że 
nigdzie nie jest zadeklarowana ilość współrzędnych. A nie wiem jak 
radzić sobie z tablicami zawartymi w typach obiektowych oracla.

Pozdrawiam Ciekawy


---
Ta wiadomość e-mail jest wolna od wirusów i złośliwego oprogramowania, ponieważ ochrona avast! Antivirus jest aktywna.
http://www.avast.com

> Tylko, że o ile proces pobierania danych wraz z rysowaniem trwa 1 min 25
> to samo pobieranie danych "czyste" 1 minuta 15. Stąd mój wniosek, że coś jest 
> nie tak z pobieraniem danych. Zresztą duże programy komercyjne i niekomercyjne 
> rysują tą samą mapę od 17 do 19 sekund. Kiedy korzystałem z UNIDACA mój robił 
> to w 25 sek.
Dobrze pobierasz je i co z nimi robisz od razu rysujesz (Canvas), wpisujesz do 
tablicy, buforujesz jakoś "cy cóś"? 

W dniu 2014-06-05 08:21, konsul41@wp.pl pisze:

> Dobrze pobierasz je i co z nimi robisz od razu rysujesz (Canvas),
> wpisujesz do tablicy, buforujesz jakoś "cy cóś"?

tutaj zaczyna się to czym się tak na prawdę bawię czyli tworzenie warstw 
obiektów taki cad lub gis jak kto woli, ale koniec końców jest
to wrzucone na canvas. Tylko że w tym nie widzę problemu bo testuję 
końcowe rozwiązanie porównując z innymi aplikacjami tego typu.

Mój problem po wczorajszym testowaniu polega na tym że:

1. do aplikacji muszę wprowadzić obiekty graficzne za pomocą formatu 
WKB, (well known binary) taki standard który został wymyślony do 
binarnej reprezentacji obiektów gisowych

2. oracle przechowuje dane geomeryczne za pomocą "swojego standardu"
udostępnia jednak funkcję get_wkb tworzącą BLOBy w ogólnym standardzie i 
fajnie mógłbym to wykorzystać i zapomnieć o temacie, ale funkcja ta 
generuje makabryczne opóźnienia i nie jestem pewien zaraz to będę 
sprawdzał ale coś mi się wydaje, że te BLOBy są nadmiarowe.

3. Stąd wniosek, że chcąc nie chcąc muszę się "poznać" na oraclu i jego 
typach, bo zastosowanie UNIDaca zamiast ZEOSa tylko optymalizuje problem 
który nadal istnieje.

Pozdrawiam Ciekawy


---
Ta wiadomość e-mail jest wolna od wirusów i złośliwego oprogramowania, ponieważ ochrona avast! Antivirus jest aktywna.
http://www.avast.com

> 2. oracle przechowuje dane geomeryczne za pomocą "swojego standardu"
> udostępnia jednak funkcję get_wkb tworzącą BLOBy w ogólnym standardzie i 
> fajnie mógłbym to wykorzystać i zapomnieć o temacie, ale funkcja ta generuje 
> makabryczne opóźnienia i nie jestem pewien zaraz to będę sprawdzał ale coś mi 
> się wydaje, że te BLOBy są nadmiarowe.


Bardziej chodziło mi o to czy w jakiś sposób buforujesz te pliki, trzymasz kopię 
lokalną, czy robisz bezpośrednie Canvas.Draw.
Pokaż w jaki sosób pobierasz te bloby z komponentów bazodanowych w obu 
przypadkach.

W dniu 2014-06-05 10:22, konsul41@wp.pl pisze:

>
> Bardziej chodziło mi o to czy w jakiś sposób buforujesz te pliki,
> trzymasz kopię lokalną, czy robisz bezpośrednie Canvas.Draw.
> Pokaż w jaki sosób pobierasz te bloby z komponentów bazodanowych w obu
> przypadkach.
>

buforem jest warstwa która pobiera tyle geometrii ile "widzi ekran"
z bazy danych. Następnie już po pobraniu przerysowuje.
"wąskie gardło" całego procesu to zaczytanie geometrii z bazy danych 
oracla i tylko z tej do warstwy.

Sprawa druga BLOBy nie są nadmiarowe. Ich przeciętna wielkość size
to 150, zdarzają się i po 2000 jak ktoś generował kształt z gpsa, ale to 
aplikacja musi obsłużyć, to sprawa użytkownika co i jak sobie wprowadza. 
(choć to bez sensu moim zdaniem).

---
Ta wiadomość e-mail jest wolna od wirusów i złośliwego oprogramowania, ponieważ ochrona avast! Antivirus jest aktywna.
http://www.avast.com

Pytanie było jak pobierasz obrazki z komponentów.
czyli jak wyciągasz je po wykonaniu SQL i co dalej z nimi robisz , przechowujesz 
je w jakiejś tablicy, przycinasz i od razu wyświetlasz? 

W dniu 2014-06-04 12:35, miab pisze:

> Dziwna sytuacja to jest pewnie wtedy jak IDE Delphi nie widzi biblioteki.
> Dlatego ja zawsze w środowisku deweloperskim umieszczam odpowiednie
> biblioteki linkowane dynamicznie tak żeby je Delphi bez problemów widziało.
>
> miab
>
sytuacja wygląda tak, jeżeli wrzucam dll do katalogu w którym mam 
aplikację, wszystko działa ok. Tyle że mam kilka aplikacji w pakiecie,
każda z nich potrzebuje dostępu do dllek i dla tego zrobiłem katalog 
shareddata w którym trzymałem dll a w trakcie startu aplikacji, 
przekazywałem lokalizację plików poprzez zconnection.libraryLocation.
I tutaj o dziwo raz ładuje, a czasem po prostu wywala błąd, z przyczyn 
których nie jestem w stanie dociec. Więc "wyluzowałem" się i wrzucam dll 
do katalogu każdej aplikacji.

Pozdrawiam Cielawy

---
Ta wiadomość e-mail jest wolna od wirusów i złośliwego oprogramowania, ponieważ ochrona avast! Antivirus jest aktywna.
http://www.avast.com

W dniu 2014-06-05 11:44, konsul41@wp.pl pisze:
> Pytanie było jak pobierasz obrazki z komponentów.
> czyli jak wyciągasz je po wykonaniu SQL i co dalej z nimi robisz ,
> przechowujesz je w jakiejś tablicy, przycinasz i od razu wyświetlasz?

Tablicą, ogólnie mówiąc jest TRRLayer - warstwa która przechowuje 
kształty. Kształty nie są obrazkami tylko danymi geometrycznymi, do 
wyrysowania. Nie muszę ich przycinać bo w pierwszej fazie zapytanie 
generowanie do bazy filtruje tylko te obietkty które się mieszczą, w 
moim zakresie. Przepraszam Cię nie chciałbym być odebrany, że się 
"mądrkuję", ale to jest praca którą się zajmuję od kilku lat i temu 
przrysowywaniu służy cała logika aplikacji, więc ciężko mi sprawę 
uprościć i napisać Ci w kilku zdaniach.
Tu są takie dość podstawowe informacje:
http://en.wikipedia.org/wiki/Well-known_text
Moim problemem w tej chwili jest po prostu niewiedza z zakresu Oracla.
Zresztą mam kilka pytań do kolegów, ale chyba wrzucę to w nowy wątek.
Bo przyczyna moich problemów leży w odczytywaniu danych obiektowych.

Pozdrawiam Ciekawy





---
Ta wiadomość e-mail jest wolna od wirusów i złośliwego oprogramowania, ponieważ ochrona avast! Antivirus jest aktywna.
http://www.avast.com

W dniu 2014-06-05 11:17, Ciekawy pisze:
> W dniu 2014-06-05 10:22, konsul41@wp.pl pisze:
>
>>
>> Bardziej chodziło mi o to czy w jakiś sposób buforujesz te pliki,
>> trzymasz kopię lokalną, czy robisz bezpośrednie Canvas.Draw.
>> Pokaż w jaki sosób pobierasz te bloby z komponentów bazodanowych w obu
>> przypadkach.
>>
>
> buforem jest warstwa która pobiera tyle geometrii ile "widzi ekran"
> z bazy danych. Następnie już po pobraniu przerysowuje.
> "wąskie gardło" całego procesu to zaczytanie geometrii z bazy danych
> oracla i tylko z tej do warstwy.
>
> Sprawa druga BLOBy nie są nadmiarowe. Ich przeciętna wielkość size
> to 150, zdarzają się i po 2000 jak ktoś generował kształt z gpsa, ale to
> aplikacja musi obsłużyć, to sprawa użytkownika co i jak sobie wprowadza.
> (choć to bez sensu moim zdaniem).

Jeśli uważasz, że wąskim gardłem jest pobieranie z bazy danych to może 
kwestia indeksów tabeli. Pokaż definicję tabeli, indeksów, zapytanie 
(pełne, bez własnych komentarzy) i plan zapytania, którym pobierasz dane.

-- 
z pozdrowieniami
Adam Siwoń

W dniu 2014-06-05 11:48, Ciekawy pisze:
> W dniu 2014-06-04 12:35, miab pisze:
>
>> Dziwna sytuacja to jest pewnie wtedy jak IDE Delphi nie widzi biblioteki.
>> Dlatego ja zawsze w środowisku deweloperskim umieszczam odpowiednie
>> biblioteki linkowane dynamicznie tak żeby je Delphi bez problemów
>> widziało.
>>
>> miab
>>
> sytuacja wygląda tak, jeżeli wrzucam dll do katalogu w którym mam
> aplikację, wszystko działa ok. Tyle że mam kilka aplikacji w pakiecie,
> każda z nich potrzebuje dostępu do dllek i dla tego zrobiłem katalog
> shareddata w którym trzymałem dll a w trakcie startu aplikacji,
> przekazywałem lokalizację plików poprzez zconnection.libraryLocation.
> I tutaj o dziwo raz ładuje, a czasem po prostu wywala błąd, z przyczyn
> których nie jestem w stanie dociec. Więc "wyluzowałem" się i wrzucam dll
> do katalogu każdej aplikacji.

Czyli nie zrozumiałeś tego co napisałem.

miab

W dniu 2014-06-04 22:20, Ciekawy pisze:
>
>>> Nowa wersja zeszła z zapytaniem testowym do 1 min i 25 sek.
>>
>> A zobacz W ZQuery Options-doCachedLobs na True i jeszcze FetchRow więcej
>> niż zaczytujesz.
>>
>> miab
>>
> Niestety UniDac również, jest nie do przyjęcia po zapytaniu i zamknięciu
> datasetu zwalnia bardzo długo pamięć blokując program.
> Jedyne wyjście to przeniesienie funkcji, Get_WKB() na klienta.
> Będę miał prośbę o naukę do kolegów jutro, bo słabo stoję z Oraclem a
> jeszcze słabiej z możliwościami poszczególnych DAO.
> Odczyt współrzędnych z obiektu to co jest mi tak na prawdę potrzebne
> trwa mniej jedna sekunda dla 22000 obiektów, problem polega na tym,że
> nigdzie nie jest zadeklarowana ilość współrzędnych. A nie wiem jak
> radzić sobie z tablicami zawartymi w typach obiektowych oracla.

Czyli nie spróbowałeś tego co napisałem.

miab

> Tablicą, ogólnie mówiąc jest TRRLayer - warstwa która przechowuje kształty. 
> Kształty nie są obrazkami tylko danymi geometrycznymi, do wyrysowania. Nie 
> muszę ich przycinać bo w pierwszej fazie zapytanie generowanie do bazy 
> filtruje tylko te obietkty które się mieszczą, w moim zakresie. Przepraszam 
> Cię nie chciałbym być odebrany, że się "mądrkuję",

Źle mnie zrozumiałeś, Ja się zastanawiam nad tym gdzie jest wąskie gardło i może 
coś się chrzani w miejscu połączenia twojego algorytmu z komponentami lub 
dodatkowe buforowanie, a nie w rysowaniu danych. 

> Jeśli uważasz, że wąskim gardłem jest pobieranie z bazy danych to może
> kwestia indeksów tabeli. Pokaż definicję tabeli, indeksów, zapytanie
> (pełne, bez własnych komentarzy) i plan zapytania, którym pobierasz dane.
>

SELECT (shape).GET_WKB() as WKBHAPE  FROM STACJE_TRANSF WHERE 
SDO_ANYINTERACT(STACJE_TRANSF.shape , SDO_GEOMETRY(2003,2123, NULL, 
SDO_ELEM_INFO_ARRAY(1,1003,3),'+'SDO_ORDINATE_ARRAY(540000,740000, 
560000,760000))) = 'TRUE'

Stosuję tylko takie zapytanie.
SDO_ANYINTERACT - funkcja która sprawdza czy mój kształt zaiwera się w 
zakresie
540000,740000, 560000,760000 - współrzędne prostokątne płaskie 
odwzorowania geograficznego
2123 - nr odwzorowania

Wszystko co jest po SDO_GEOMETRY tworzy kwadrat który jest 
odzwierciedleniem, mojego ekranu w aplikacji

Tabela Stacje_transf zawiera pola
shape - pole przechowujące geometrie,
jest zindexowana indexem geograficznym
Nie mogę zrobić nic z indexami ani z tabelą bo w skrócie sytuacja 
wygląda tak. Użytkownik a od użytkownika b dosteje dostęp do jego bazy 
trybie tylko do odczytu. Łączy się robi swoją analizę w trybie tylko do 
odczytu i rozłącza się.
Da się to zrobić wydajniej niż ja mam to zrobione.

Pozdrawiam Ciekawy



---
Ta wiadomość e-mail jest wolna od wirusów i złośliwego oprogramowania, ponieważ ochrona avast! Antivirus jest aktywna.
http://www.avast.com

W dniu 2014-06-04 18:05, miab pisze:
>
> A zobacz W ZQuery Options-doCachedLobs na True i jeszcze FetchRow więcej
> niż zaczytujesz.
>

>
  tylko kurcze ja nawet nie mam opcji doCachedLobs

---
Ta wiadomość e-mail jest wolna od wirusów i złośliwego oprogramowania, ponieważ ochrona avast! Antivirus jest aktywna.
http://www.avast.com

W dniu 2014-06-05 13:17, Ciekawy pisze:
>
>> Jeśli uważasz, że wąskim gardłem jest pobieranie z bazy danych to może
>> kwestia indeksów tabeli. Pokaż definicję tabeli, indeksów, zapytanie
>> (pełne, bez własnych komentarzy) i plan zapytania, którym pobierasz dane.
>>
>
> SELECT (shape).GET_WKB() as WKBHAPE  FROM STACJE_TRANSF WHERE
> SDO_ANYINTERACT(STACJE_TRANSF.shape , SDO_GEOMETRY(2003,2123, NULL,
> SDO_ELEM_INFO_ARRAY(1,1003,3),'+'SDO_ORDINATE_ARRAY(540000,740000,
> 560000,760000))) = 'TRUE'
>
> Stosuję tylko takie zapytanie.
> SDO_ANYINTERACT - funkcja która sprawdza czy mój kształt zaiwera się w
> zakresie
> 540000,740000, 560000,760000 - współrzędne prostokątne płaskie
> odwzorowania geograficznego
> 2123 - nr odwzorowania
>
> Wszystko co jest po SDO_GEOMETRY tworzy kwadrat który jest
> odzwierciedleniem, mojego ekranu w aplikacji
>
> Tabela Stacje_transf zawiera pola
> shape - pole przechowujące geometrie,
> jest zindexowana indexem geograficznym
> Nie mogę zrobić nic z indexami ani z tabelą bo w skrócie sytuacja
> wygląda tak. Użytkownik a od użytkownika b dosteje dostęp do jego bazy
> trybie tylko do odczytu. Łączy się robi swoją analizę w trybie tylko do
> odczytu i rozłącza się.

No Ok. Przyjmijmy, że indeks masz i jest w porządku, ale podaj jeszcze 
plan wykonania zapytania, żebyśmy mogli zobaczyć czy serwer bazy danych 
faktycznie korzysta z tego indeksu. Ktoś wcześniej pisał Ci, żebyś 
wykonał to samo zapytanie w innym narzędziu (sqlplus/PLSQL Developer/czy 
czego tam używasz) i zmierzył czas wykonania. Nie widziałem Twojej 
odpowiedzi. Zrobiłeś to? Będziesz miał jakieś wtedy jakieś wskazanie czy 
to faktycznie problem zapytania czy może jednak warstwy DAL (a właściwie 
ustawienia jej parametrów).

-- 
z pozdrowieniami
Adam Siwoń

W dniu 2014-06-05 13:37, Ciekawy pisze:
> W dniu 2014-06-04 18:05, miab pisze:
>>
>> A zobacz W ZQuery Options-doCachedLobs na True i jeszcze FetchRow więcej
>> niż zaczytujesz.
>>
>
>>
>   tylko kurcze ja nawet nie mam opcji doCachedLobs

W ZEOS 7.2.0-alfa powinna być.

miab

W dniu 2014-06-05 12:38, miab pisze:
>
>
> Czyli nie zrozumiałeś tego co napisałem.
>
> miab
>
W dniu 2014-06-05 12:38, miab pisze:
 >
 >
 > Czyli nie zrozumiałeś tego co napisałem.
 >
 > miab
 >
święte słowa nie zrozumiałem. Zarzuciłem dependecy walker i wczytuje 
biblioteka po bibliotece i jest ok.
Chyba jedyna metoda, żeby mieć pewność, że biblioteka się załaduje. Dzięki

Pozdrawiam Ciekawy

W dniu 2014-06-04 10:29, Ciekawy pisze:
> Witam
>
> Szukałem możliwości poprawienia wydajności w tym celu zmieniłem dostęp
> do danych z ZEOS na UNIDac.

Spróbuj  wersja ZEOS-a 7.2 Revision 3160(lub więcej):
http://svn.code.sf.net/p/zeoslib/code-0/branches/testing-7.2/
Oracle w niektórych testach kilkukrotnie przyspieszył.

miab

W dniu 2014-06-20 18:05, miab pisze:
> W dniu 2014-06-04 10:29, Ciekawy pisze:
>> Witam
>>
>> Szukałem możliwości poprawienia wydajności w tym celu zmieniłem dostęp
>> do danych z ZEOS na UNIDac.
>
> Spróbuj  wersja ZEOS-a 7.2 Revision 3160(lub więcej):
> http://svn.code.sf.net/p/zeoslib/code-0/branches/testing-7.2/
> Oracle w niektórych testach kilkukrotnie przyspieszył.

Szczególnie właśnie przy czytaniu danych.

miab

W dniu 2014-06-20 18:05, miab pisze:
> W dniu 2014-06-04 10:29, Ciekawy pisze:
>> Witam
>>
>> Szukałem możliwości poprawienia wydajności w tym celu zmieniłem dostęp
>> do danych z ZEOS na UNIDac.
>
> Spróbuj  wersja ZEOS-a 7.2 Revision 3160(lub więcej):
> http://svn.code.sf.net/p/zeoslib/code-0/branches/testing-7.2/
> Oracle w niektórych testach kilkukrotnie przyspieszył.

A jeszcze lepiej 7.2 Revision 3188(lub więcej):
http://svn.code.sf.net/p/zeoslib/code-0/branches/testing-7.2/
, która jest znblizona do wersji ZEOS 7.2-beta,
która niedługo powinna się ukazać.
Poprawiono w niej szereg drobnych błędów, w tym kompatybilność z
najnowszymi fpc/Lazarus i Delphi XE6 i zdecydowanie przyspieszono i 
poprawiono prace z Oracle.

miab

W dniu 2014-06-20 18:05, miab pisze:
> W dniu 2014-06-04 10:29, Ciekawy pisze:
>> Witam
>>
>> Szukałem możliwości poprawienia wydajności w tym celu zmieniłem dostęp
>> do danych z ZEOS na UNIDac.
>
> Spróbuj  wersja ZEOS-a 7.2 Revision 3160(lub więcej):
> http://svn.code.sf.net/p/zeoslib/code-0/branches/testing-7.2/
> Oracle w niektórych testach kilkukrotnie przyspieszył.

ZEOS-a 7.2 Revision 3227 wyglada na b. stabilną.
D7-DX6, fpc/Lazarus.
Polecam zainteresowanym ZEOS-em.

miab

W dniu 2014-06-20 18:05, miab pisze:
> W dniu 2014-06-04 10:29, Ciekawy pisze:
>> Witam
>>
>> Szukałem możliwości poprawienia wydajności w tym celu zmieniłem dostęp
>> do danych z ZEOS na UNIDac.
>
> Spróbuj  wersja ZEOS-a 7.2 Revision 3160(lub więcej):
> http://svn.code.sf.net/p/zeoslib/code-0/branches/testing-7.2/
> Oracle w niektórych testach kilkukrotnie przyspieszył.


Wersja ZEOS 7.2 Revision 3232 (bliska beta):
http://svn.code.sf.net/p/zeoslib/code-0/branches/testing-7.2/
http://zeoslib.sourceforge.net/viewtopic.php?f=40&t=3795&p=30464#p30464
http://sourceforge.net/p/zeoslib/code-0/commit_browser
D7-DXE6; fpc/Lazarus
(a tak naprawdę lepsza niż poprzednie wersje stabilne).

miab