אופטימיזציה ב-vb6

[dovid]

@mat

כל הטיעונים שהבאת פשוט לא נכונים. הרבה יותר מורכב לפתח לשולחני. ודו"ק.

תוכל לתת דוגמה למורכבות כל שהיא?

נתעלם מבעיית הפלטפורמות שהרי הוא אמר מפורש שלא על זה הוא דן (פעמים שזה לא פרמטר).

פורסם במקור בפורום CODE613 ב04/04/2016 12:23 (+03:00)

[magicode]

הוא טען בלי להסביר שום דבר. השאיר אותנו עם דו"ק. גם זכותי לעשות את זה.

פורסם במקור בפורום CODE613 ב04/04/2016 15:01 (+03:00)

[dovid]

@mat

הוא טען בלי להסביר שום דבר. השאיר אותנו עם דו"ק. גם זכותי לעשות את זה.

הסביר דוקא על שהווב כופה אותך לחלק את אפליקציה שלך לשתיים לגמרי. עם תקשורת פרימיטיבית ביניהם
ושצריך לדאוג לאיזשהוא שרת קרוב או רחוק, שבכל מקרה רחוק מהלב (רק בשביל החשבונית, איפה שאני עובד משלמים לחברה מקומית שלוקחת הון. על מה? על חשבונית מסודרת ועל כאב הראש של איפה איך ומה קורה עם זה).
הוא טען על ביצועים. וזה הן בצד הקליינט והן בשרת. בשתיהם אתה מצד אחד מפסיד. בדרך כלל מרויח אבל ודאי שיש הפסד שבמקרים ספציפיים מהוה שיקול.

אבל אכן רוב התוכנות לא במטריה הזאת, ורוב התוכנות בלאו הכי צריכות צד שרת (נתונים ואבטחה ועוד) וממילא במקרים אלו טיעונים אלו נופלים בדרך כלל לחלוטין.

פורסם במקור בפורום CODE613 ב04/04/2016 15:46 (+03:00)

[magicode]

הטיעון היחידי שהיה לנו פה זה צד שרת וצד לקוח. כל השאר. לא נכון. הטיעונים האלו נובעים מחוסר היכרות עם המנגנונים.

לגבי הטיעון של צד שרת לקוח זה נכון רק לגבי מעבר מידע ענק בין השרת לתצוגה. כולמר אם אני מעביר סרט או משהו כזה. שאר דברים לא נכונים בכלל לעניין הזה. ויותר קל לבצע ב WEB.
יתרונות ב WEB.
בצד שרת לעולם לא יכול לבוא משועמם פלוני ולפרוץ לך את התוכנה שעמלת עליה בהרבה כסף.
הביצועים אצל הלקוח לא קיימים כי הכל אצלך בשרת ואתה יכול לדאוג לשרת יותר טוב
אין צורך לעדכן תוכנות אצל הלקוח. את מעדכן בשניה גירסה.
אם אתה מוסיף חומר לתוכנה היא מתעדכנת מייד לא צורך להתעדכן.
אתה לא צריך להתמודד עם תוכנות שנפגמו אצל הלקוח.
אם אתה עושה מנוע חיפוש למשל. אתה יכול להקצות בשרת 50 גיגה ראם לצורך חיפוש מהיר במיוחד.

אני לא יודע מה האיש " meir n" עושה ומה התוכנה שלו עושה.
לכן אני ממליץ לעבור ל WEB. במקרה שזה לא תוכנה לעריכת וידאו.

פורסם במקור בפורום CODE613 ב04/04/2016 16:10 (+03:00)

[dovid]

כל ההודעה שלך היא מעלות. וזה לא מתבקש כאן. המעלות ישנם, לא התווכחו.

הטיעון של שרת לקוח לא קשור לכמות המידע. אתה לא הבנת. לתקף ("הזן שם מעל 4 תוים") אתה צריך פעמיים? זה סרבול ששמו שרת ולקוח. לא קשור לתעבורת חומר. הפירמוורקים עושים זאת אוטומטית אבל לכל אוטומציה יש מחיר של בלגן מתחת למכסה של המנוע.
אם לא מדובר בנוד, אתה גם חייב לכתוב את כל המודל וגם הרבה לוגיקה פעמיים. אתה לא אמרת נוד, אמרת ווב.

אשמח להבין למה אחרי שהסברתי, אתה פוטר את עצמך במשפט דומה ל"ודוק":
"כל השאר. לא נכון. הטיעונים האלו נובעים מחוסר היכרות עם המנגנונים."
למה?

בקשר לביצועים, אני כתבתי שלעיתים אין לך עבודה שחורה להעביר לצד השרת, ממילא לא הקלת על צד הלקוח בכלום.

פורסם במקור בפורום CODE613 ב04/04/2016 16:55 (+03:00)

[avr416]

דווקא נראה לי שהסברתי וכתבתי קצת יותר מודו"ק..
אבל אם זה לא היה מובן, אז ארחיב מעט יותר.

באמת אין לי ניסיון, אבל מהקצת שיש לי ראיתי שיש מעלות לכאן ולכאן.
כתבתי תוכנה של ניהול תורמים ותרומות (או אנשי קשר ותשלומים זה לא בדיוק משנה..) בהתחלה כתבתי אותה בפלטפורמה שולחנית (WPF), ואח"כ בפלטפורמה וובית (ASP.NET MVC).
הייתרונות של הווב בפיתוח הם - עושר של ספריות עיצוב, כך שאפשר לעצב את הUI בקלות כך שיראה מודרני ועדכני, בלא צורך להתאמץ כ"כ, מה שבWPF הרבה יותר קשה כי את הכל אתה צריך לכתוב לבד, וצריך להכיר את WPF בצורה טובה כדי לדעת איך בדיוק לעצב. (גם בווב צריך לדעת, אבל שם יש הרבה דברים מוכנים שמספיק לך לעשות רק התאמות פשוטות).
בנקודה הזו - אני מסכים עם MAT שהרבה יותר קל לפתח לווב, כיון שיש הרבה ספריות מוכנות וחינמיות, מה שאין כן בWPF ודומיו. אם כי לכן הוספתי שבפלטפורמה החדשה (UWP) ראיתי (לא ניסיתי..) שיש אפשרות לפתח רק עם JS וHTML שאולי זה קצת מוריד את הייתרון הזה, כיון שלא צריך ללמוד שפה חדשה (XAML)..
מאידך, אם אתה רוצה לעשות דטה-בינדיג דו כיווני אז זה הרבה יותר מסובך וצורך ביצועים בווב, משא"כ באפליקציה שולחנית, הלא כן? אמנם באנגולר 2 שיפרו את הנקודה הזו, אבל דווקא אתה המלצת שלא לעבור לגרסא2 אלא להשאר בגרסא אחת..
כמו כן, כל פעם שאתה קורא לשרת, אז הוא פונה לדטה בייס וטוען את הנתונים ושולח לך את המידע. משא"כ כשהאובייקט חי ברקע, ואתה פשוט יכול לגשת אליו מכל מקום..
ואפליקציה כזאת - איזה צורך יש שהיא תהיה וובית? הרי בכל מקרה לרוב המשרדים יש וינדוס אז מדוע לא לכתוב ישר אפליקציה שולחנית? כך גם מבחינת אבטחה הרבה יותר פשוט.
אתה צודק שאכן לא הכרתי את הנקודות שהעלית, (כמו עדכוני גרסא, ופריצה של תוכנה), וכמו שדוד ל.ט. אמר אכן אולי בכל מקרה יש צורך לגבות את הנתונים בשרת וכו', אבל אני חושב שצריך לבחון כל מקרה לגופו.

פורסם במקור בפורום CODE613 ב04/04/2016 18:51 (+03:00)

[softs]

אפשר לקבל ולשלוח מידע בינארי עם http אבל זה לא עוזר למה שאמרת "לדבר עם השרת בשפת תכנות", בשביל להשיג תוצאה כזו עולה ברעיוני שאפשר להשתמש ב websockets עם איזשהו eval בצד השרת וגם להיפך לשלוח פקודות js לקליינט ולבצע eval בקליינט

פורסם במקור בפורום CODE613 ב04/04/2016 22:38 (+03:00)

[רחמים]

@ארכיטקט

@רחמים
וכל הדפדפנים מציגים HTTP

אתה מבלבל אולי בין HTTP לבין HTML??? אין שום קשר בין הדברים, דפדפנים יודעים לרנדר טקסט של HTML לתצוגה, אני מדבר על פרוטוקול שניתן להעביר בו מידע קצת מעבר לטקסט, ולדבר עם השרת בשפת תיכנות, ולא להמיר כל הזמן טקסט למשמעויות שונות, האם זה אפשרי?? ייתכן שלא.

בשביל זה לא צריך פרוטוקול חדש שכל הדפדפנים יצטרכו ללמוד, פשוט ספריית עזר שתהיה בצד שרת ובצד לקוח, ואתה תדבר עם הספריה בשפת תיכנות והיא תתרגם את זה ל HTTP ובחזרה.

אגב, HTTP ו HTML הם צמד חמד, HTML זה HyperTextMarkup Language, ו HTTP זה HypertextTransfer Protocol

פורסם במקור בפורום CODE613 ב05/04/2016 09:45 (+03:00)

[dovid]

@avr416

מאידך, אם אתה רוצה לעשות דטה-בינדיג דו כיווני אז זה הרבה יותר מסובך וצורך ביצועים בווב, משא"כ באפליקציה שולחנית, הלא כן? אמנם באנגולר 2 שיפרו את הנקודה הזו, אבל דווקא אתה המלצת שלא לעבור לגרסא2 אלא להשאר בגרסא אחת..
כמו כן, כל פעם שאתה קורא לשרת, אז הוא פונה לדטה בייס וטוען את הנתונים ושולח לך את המידע. משא"כ כשהאובייקט חי ברקע, ואתה פשוט יכול לגשת אליו מכל מקום..

הבינדינג הדו כיווני זה עניין של תכנון. לא חייבים אותו, ואם חייבים זה אפשרי בכל פלטפורמה, לא כ"כ קשה. הביצועים לעניין זה לא מעניינים באמת מישהו.

בקשר לטעינות מיותרות מהDB אז זה גם עניין של תכנון כמו שארכיטקט כתב. אבל גם אם כן, אז מה?

פורסם במקור בפורום CODE613 ב05/04/2016 12:05 (+03:00)

[ארכיטקט]

@mat

אבל זה כבר דפוק לנסות לבנות את הווב בראש שולחני. צריך לבנות ווב בראש של ווב.

אופס... דנים כאן על איך לבנות את הראש :? :? :?

פורסם במקור בפורום CODE613 ב05/04/2016 20:58 (+03:00)

[magicode]

כל הישויות המורכבות של DOTNET. מוכרבות בסופו של דבר ממידע בינארי פשוט.
אתה גם יכול לממש את זה על איזה תקן משלך.
אני חושב שבטלריק אתה יכול לקבל תמורת תשלום פקדים חיים. באותו טכנולוגיה כמו שיש בשולחני.
אבל זה כבר דפוק לנסות לבנות את הווב בראש שולחני. צריך לבנות ווב בראש של ווב.

פורסם במקור בפורום CODE613 ב05/04/2016 17:56 (+03:00)

[dovid]

@ארכיטקט

אין אפשרות לפתח פרוטוקול שיתמוך בישויות מורכבות????
או שאני מדבר מתוך עם הארצות ובורות גמורה, ואולי יש איזה סוד כמוס שהפרוטוקול צריך להעביר טקסט דייקא ולא מצביעים לאובייקטים :? :? :?

ברגע שאין לך מצביע לזיכרון, התקשורת היחידה שיש זה סריאליזציה לטקסט או בתים וחזרה. אין דרך אחרת. ישויות מורכבות זה לא בעיה, כי יש פורמטים בינאריים וטקסטואליים שעושים זאת יופי אבל עדיין זה לא יהיה מצביע לזיכרון. אפי' באותה המכונה מתוכנה לתוכנה קשה להיעזר במצביעים.

אתם פתאום עוברים לדבר על "שליחת הוראות" מהשרת ללקוח וזה גם צורך של חוסר תכנון. אין שום טעם במצב הזה.

פורסם במקור בפורום CODE613 ב05/04/2016 12:08 (+03:00)

[ארכיטקט]

@רחמים

וכל הדפדפנים מציגים HTTP

אתה מבלבל אולי בין HTTP לבין HTML??? אין שום קשר בין הדברים, דפדפנים יודעים לרנדר טקסט של HTML לתצוגה, אני מדבר על פרוטוקול שניתן להעביר בו מידע קצת מעבר לטקסט, ולדבר עם השרת בשפת תיכנות, ולא להמיר כל הזמן טקסט למשמעויות שונות, האם זה אפשרי?? ייתכן שלא.

פורסם במקור בפורום CODE613 ב04/04/2016 20:52 (+03:00)

[רחמים]

@ארכיטקט

@דוד ל.ט.
עם תקשורת פרימיטיבית ביניהם

כמה שזה נכון!!! בתחילת דרכי עם עולם הווב, לקח לי כמה חודשים לעכל שכל הפלט והקלט של HTTP זה טקסט בלבד, ט-ק-ס-ט כמה פרימיטיבי. את הכל עיקמו בשביל ליישר קו עם הפרוטוקול הזה, עשו Base64, מאות אלפי פריימוורקים ליצור הפשטה של כל העסק הזה.
וכל כך למה כי תמיד יש רק מדען אחד שממציא משהו פעם במאה שנה (פרוטוקול HTTP במקרה שלנו) וכל החברות המסחריות פרזיטים בני פרזיטים, רק מחפשים איך אפשר לעשות כסף מההמצאה שלו וכמה שיותר מהר. אין אפשרות לפתח פרוטוקול שיתמוך בישויות מורכבות????
או שאני מדבר מתוך עם הארצות ובורות גמורה, ואולי יש איזה סוד כמוס שהפרוטוקול צריך להעביר טקסט דייקא ולא מצביעים לאובייקטים :? :? :?

הסיבה שלא עברו לפרוטוקול אחר היא שבסופו של דבר הלקוח רואה את האתר שלך בדפדפן, ולכל אחד יש דפדפן שהוא אוהב וכל הדפדפנים מציגים HTTP, אם היית מביא ללקוח את האתר ביחד עם הדפדפן היית מתקשר בין השרת ללקוח עם איזה פרוטוקול שתרצה, אבל אתה נתון לחסדי כרום ופיירפוקס ואקספלורר....

פורסם במקור בפורום CODE613 ב04/04/2016 19:44 (+03:00)

[ארכיטקט]

@avr416

כמו כן, כל פעם שאתה קורא לשרת, אז הוא פונה לדטה בייס וטוען את הנתונים ושולח לך את המידע. משא"כ כשהאובייקט חי ברקע, ואתה פשוט יכול לגשת אליו מכל מקום..

מי הכריח אותך "להרוג" אובייקטים בשרת?? זה עניין של ארכיטקטורה מקובלת, והתפיסה של ווב היא שאתה צריך להפגין יכולת עמידה בעומסים כי אולי יום אחד תהיה גוגל, אבל הבחירה בידיך להשאיר אובייקטים חיים בשרת (על ידי static או פשוט להצמיד אותם לסשן, שזאת אפשרות לא רעה בכלל וגם מאפשרתלהרוג אותם ביחד עם הסשן שמת בלי צורך באירועים מיוחדים), יש לי המון קוד שבנוי בארכיטקטורה הזו וזה יעיל מאוד. אם אתה יודע את כמות הנתונים שלך, אתה יכול נניח פעם בעשר דקות לרענן אותם מול מסד הנתונים, או לעשות אופטימיזציה על ידי כך שרק רשומות שעודכנו לאחרונה עולות וכן הלאה. בסך הכל מחזיק אובייקטים סטטיים באפליקציה, ומהירות התגובה לא תיאמן במקרים כאלו.

פורסם במקור בפורום CODE613 ב04/04/2016 19:35 (+03:00)

[ארכיטקט]

@דוד ל.ט.

עם תקשורת פרימיטיבית ביניהם

כמה שזה נכון!!! בתחילת דרכי עם עולם הווב, לקח לי כמה חודשים לעכל שכל הפלט והקלט של HTTP זה טקסט בלבד, ט-ק-ס-ט כמה פרימיטיבי. את הכל עיקמו בשביל ליישר קו עם הפרוטוקול הזה, עשו Base64, מאות אלפי פריימוורקים ליצור הפשטה של כל העסק הזה.
וכל כך למה כי תמיד יש רק מדען אחד שממציא משהו פעם במאה שנה (פרוטוקול HTTP במקרה שלנו) וכל החברות המסחריות פרזיטים בני פרזיטים, רק מחפשים איך אפשר לעשות כסף מההמצאה שלו וכמה שיותר מהר. אין אפשרות לפתח פרוטוקול שיתמוך בישויות מורכבות????
או שאני מדבר מתוך עם הארצות ובורות גמורה, ואולי יש איזה סוד כמוס שהפרוטוקול צריך להעביר טקסט דייקא ולא מצביעים לאובייקטים :? :? :?

פורסם במקור בפורום CODE613 ב04/04/2016 19:31 (+03:00)

[magicode]

כל הטיעונים שהבאת פשוט לא נכונים. הרבה יותר מורכב לפתח לשולחני. ודו"ק.

פורסם במקור בפורום CODE613 ב04/04/2016 00:36 (+03:00)

[avr416]

@mat

התשובה שלי נכונה גם לשאלה הקודמת שלך. עניתי לך תשובה לשני הבעיות.

אמנם אינני ראוי לחלוק על mat, כיון שאין לי את הידע והניסיון שלו.
אך נראה לי שלא כל דבר יותר טוב לפתח בצורה וובית, יש דברים שאין שום צורך שיהיו בווב וממילא יותר פשוט לפתח אותם בפלטפורמה שולחנית (wpf, או הפלטפורמה החדשה של וינדוס - Universal Windows Platform - UWP שמאפשרת לפתח אפי' ללא ידע בC# אלא רק JS, HTML, CSS אם הבנתי נכון. עיין כאן, ו כאן).
כיון שפיתוח לווב הוא הרבה יותר מורכב שהרי התוכנה מתחלקת לקליינט ולסרבר, וממילא כל הזמן צריך לעדכן את הקליינט ולבדוק איזה אובייקט השתנה, וממילא יש את כל הספריות כדוגמת אנגולר וכדו' שצורכים הרבה ביצועים וכו'. דברים שבפיתוח שולחני הרבה יותר פשוט לעשות אותם כיון שכל הזמן יש לך אובייקט שחי ברקע, וכשמשהו משתנה - יודעים בדיוק מה השתנה ואפשר לעדכן את החלק של הUI שצריך, ולא לבדוק שוב את כל הDOM.
אז נכון שפיתוח וובי הוא חוצה פלטפורמות, והוא מתאים לכל מכשיר ולא צריך להתקין אותו על כל מחשב.. אך מאידך - צריך להחזיק שרת ואבטחה וכו'.
קיצר - לכל דבר יש חסרונות ויתרונות וצריך לבדוק מה הפלטפורמה המתאימה לכל צורך.
וכמובן שאני מסכים איתו לגבי מה שהוא התכוון שצריך לעזוב את VB כמה שיותר מהר.. ולעבור למשהו קצת יותר עדכני (למרות שאינני מכיר את VB)
והנלע"ד כתבתי ודו"ק

פורסם במקור בפורום CODE613 ב03/04/2016 22:39 (+03:00)

[magicode]

התשובה שלי נכונה גם לשאלה הקודמת שלך. עניתי לך תשובה לשני הבעיות.

פורסם במקור בפורום CODE613 ב03/04/2016 22:10 (+03:00)

[softs]

יש כאן טיפים:
http://www.vb6.us/tutorials/optimizing-vb-applications
כלי בתשלום - דמו חינם לחודש עד 10 קבצי מקור:
http://www.aivosto.com/vbwatch.html

פורסם במקור בפורום CODE613 ב03/04/2016 20:01 (+03:00)