1. #1
    Membre du Club
    Profil pro
    Responsable de service informatique
    Inscrit en
    novembre 2006
    Messages
    70
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Responsable de service informatique
    Secteur : Finance

    Informations forums :
    Inscription : novembre 2006
    Messages : 70
    Points : 59
    Points
    59

    Par défaut java et vitesse de traitement

    Bonjour,

    Je voudrais avoir des avis de gens ayant l'expérience de Java, RPG et/ou COBOL sur AS400, enfin Power-I.

    Je travaille dans une entreprise dont l'applicatif général (en fait des dizaines voire des centaines de modules) sont répartis soit sur PC, soit sur OS400. En fait, toutes les données de la DB de production sont dans la DB2/400. Les programmes se répartissent en deux classes :
    - sur le mainframe les traitements qui manipulent beaucoup de données (beaucoup : des millions de records);
    - sur le PC (pgm Delphi avec lecture directe de la DB2/400 grâce à Delphi/400) quand il s'agit de traiter moins de données (quelques dizaines de milliers), de faire des IHM ou de la bureautique.

    Ma question porte en réalité sur les performances comparées entre Java et COBOL (ou RPG, peu importe). J'ai l'intuition qu'elles ne peuvent pas être du même ordre.
    Autrement dit, imaginons un programme simpliste qui :
    - balaie une vue logique de 3 millions de lignes;
    - pour chaque ligne, va chercher des informations diverses dans trois ou quatre autres tables,
    - fait pas mal de COMPUTE (calculs actuariels),
    - puis fait un REWRITE de l'article et passe au suivant.
    En fait, c'est ce que font la plupart de nos programmes 400.

    Et la question est : Est-ce que Java va aller aussi vite que COBOL ou RPG ?

    Merci d'avance de vos réponses.

    Paul Rambeaux

  2. #2
    Membre confirmé
    Homme Profil pro
    Responsable de service informatique
    Inscrit en
    octobre 2006
    Messages
    458
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Jura (Franche Comté)

    Informations professionnelles :
    Activité : Responsable de service informatique
    Secteur : Distribution

    Informations forums :
    Inscription : octobre 2006
    Messages : 458
    Points : 603
    Points
    603

    Par défaut

    Bonjour,

    Je dirais qu'il n'y aura pas photo. Les RPG/Cobol iront beaucoup plus vite que Java. Et de plus consommeront bien moins de ressources (CPU / Mémoire).
    De notre côté, nous sommes un peu dans le même cas. Nous avons commencé (c'est un long travail de développement), à basculer vers du VB .net. On aurait pu le faire avec d'autres langages disponibles dans Visual Studio, notre choix de VB est du aux compétences internes.

    Pour tout ce qui est interface, on se régale par rapport à la vieille interface "verte" (5250).
    Mais quid du traitement BD ?
    On a séparé 2 types de traitements :
    • Les traitements interface à proprement parler. L'équivalent des anciens interactifs.
      On utilise le pilote .net de DB2 directement dans notre code VB. Et les performances sont très correctes.
      Je pense qu'avec Java tu obtiendras quelque chose de plus lent, mais acceptable.
    • Les traitements lourds, ne nécessitant pas d'interface. Les anciens batchs.
      Là on crée des procédures SQL. Que ce soit en SQL pur quand le traitement peut en profiter, ou en RPGLE voire SQLRPGLE quand la complexité nécessite une approche plus "programme".

    En utilisant des procédures SQL pour les traitements batch, on évite pas mal d'inconvénients du langage de développement habituel (VB.net pour nous ou Java ).
    Alors je serai toi, je ne me poserai pas la question.
    Utilise Java pour ce qu'il sait faire, mais pas pour les traitements lourds de BD (sauf si çà passe dans quelques requêtes SQL qui seront traitées directement sur le serveur bien entendu).
    Les procédures SQL sont là pour çà.

  3. #3
    Membre averti
    Homme Profil pro
    Analyste-Programmeur as/400, Java et Windev
    Inscrit en
    août 2002
    Messages
    207
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Luxembourg

    Informations professionnelles :
    Activité : Analyste-Programmeur as/400, Java et Windev
    Secteur : Finance

    Informations forums :
    Inscription : août 2002
    Messages : 207
    Points : 303
    Points
    303

    Par défaut

    Bonjour,

    RPG et COBOL sont des langage qui sont très proche du langage machine de l'IBM i, tandis que JAVA est un langage interprété.
    Et comme le dit m4k-Hurrican, RPG et COBOL seront plus rapide, de plus, l'accès à la DB est instantanné, pas de drivers ou autre.

    Par contre, en ayant fait l'expérience, pour la saisie, un programme sur l'IBM i (bien pensé) sera toujours plus rapide que sur d'autres interfaces.

    Larry57

  4. #4
    Membre confirmé
    Homme Profil pro
    Responsable de service informatique
    Inscrit en
    octobre 2006
    Messages
    458
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Jura (Franche Comté)

    Informations professionnelles :
    Activité : Responsable de service informatique
    Secteur : Distribution

    Informations forums :
    Inscription : octobre 2006
    Messages : 458
    Points : 603
    Points
    603

    Par défaut

    Citation Envoyé par larry57 Voir le message

    Par contre, en ayant fait l'expérience, pour la saisie, un programme sur l'IBM i (bien pensé) sera toujours plus rapide que sur d'autres interfaces.

    Larry57
    Oui, mais non.
    Le problème est qu'à de rares exceptions près, les écrans verts sont absolument inutilisables de nos jours. Même pour de la saisie simple.
    Écrans trop petits pour afficher toutes les informations, problèmes d'encodage (en particulier lors de copier/coller), pas de réactivité immédiate à la saisie, pas de mise à jour temps réel des champs, pas d'affichage graphique, de glisser/déposer, etc...
    Prenons l'exemple d'un simple devis, le saisir sur la vieille interface permet d'aller vite sur le texte brut. Mais si on veut pouvoir y joindre des pdf, faire un peu de mise en page, çà oblige à des exercices qui alourdissent le traitement, et font donc perdre du temps.
    Alors ne parlons même pas de coller un texte issu d'une page web, une image, ou autre.

    IBM n'a pas fait ce qu'il fallait à l'époque ou VisualAgeRPG existait.
    Ils ont coupé l'herbe sous le pied de l'équipe qui développait cet outil (j'étais en contact avec eux car on misait beaucoup sur VARPG), en refusant qu'ils évoluent au niveau du compilateur C++. Le leur était buggué...
    Quel beau gâchis, même s'il y avait encore beaucoup de travail (bugs, simplification, accès SQL sans avoir à installer DB2 Windows, éditeur source, etc...)

    Bref, le sujet n'est pas là. Java a ses qualités, mais la vitesse justement, n'en fait pas partie.
    Reste que comme indiqué, il faudrait peut être envisager une approche SQL pure. S'il y a de la mise à jour de masse, que les calculs peuvent être fait dans la ou les requête(s) SQL et qu'elle est facilement applicable d'un point de vue chemin d'accès, il y a peut être à gagner à ce niveau.
    J'ai un exemple en tête chez nous, où la mise à jour prenait 2 mn environ avec le traitement RPG, et dure environ 10s désormais !

  5. #5
    Membre averti
    Homme Profil pro
    Analyste-Programmeur as/400, Java et Windev
    Inscrit en
    août 2002
    Messages
    207
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Luxembourg

    Informations professionnelles :
    Activité : Analyste-Programmeur as/400, Java et Windev
    Secteur : Finance

    Informations forums :
    Inscription : août 2002
    Messages : 207
    Points : 303
    Points
    303

    Par défaut

    Bonjour,

    Ayant fait du Java, la programmation de choses simples est d'une complexité ahurissante.
    De plus, les mises à jour de Java quotidienne, les fonctions qui deviennent obsolètes d'un jour à l'autre...

    Larry57

Discussions similaires

  1. [XL-2010] Recherche de solution pour accélérer vitesse de traitement : VBA + Filtre
    Par Poussemousse dans le forum Macros et VBA Excel
    Réponses: 12
    Dernier message: 22/07/2016, 21h46
  2. [XSLT 1.0] Ordre d'exécution des conditions et vitesse de traitement
    Par vogur dans le forum XSL/XSLT/XPATH
    Réponses: 1
    Dernier message: 28/12/2013, 00h21
  3. Réponses: 1
    Dernier message: 23/07/2010, 14h28
  4. Réponses: 8
    Dernier message: 19/02/2010, 16h52

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo