Если дело в функции random, то циклы разной длины, но без использования памяти под сохранение сгенерированных рандомных данных, должны давать нелинейное изменение времени исполнения. А если время линейное, то и дело - в памяти, вернее, её утилизации процессором.
Но, если поменять местами циклы, то уже первый способ (теперь уже второй) будет на порядок (20 раз) быстрее. Всё дело в кэшах, не иначе. Кэши - они разные. ideone.com/EsvPAu
Полагаю, Delphi переживёт все называемые здесь непонятные фреймворки, оболочки и библиотеки, за исключением Java и JavaScript. Вот они (и Delphi) будут жить вечно (в пределах субъективного мироощущения), но в разных объёмах и задачах :o)
Вопрос не понятен. Если есть JTable, значит есть и программа, которая уже привязывает вводимые данные в нужную строку. Но зачем txt? Зачем его выгружать? И даже загружать, видимо?
Если следует искать в текстовом файле и его же модифицировать, то откуда берётся строка поиска и из чего она состоит?
Если задача просто найти дату связанную с каким либо именем в текстовом файле и добавить в результирующий текстовый файл дополнительный столбец с дополнительными данными, то можно:
а) считать исходный txt,
б) перевести его в какую-либо структуру, обеспечивающую поиск по, например, имени и дате. Подойдёт даже Hashtable, ключом которой будут текстовая сумма искомых столбцов по каждой строке, однообразно слитых друг с другом в строку, и не повторяющиеся. А значением Hashtable будут все поля из исходного txt в форме массива строк, для простоты,
в) вводить откуда либо, пусть и из другого txt поисковые группы, связанные с новыми данными, переводя их в форму, соответствующую формату ключей нашего Hashtable,
г)далее искать в Hashtable все поступающие из второго txt уникальные элементы и, найдя, модифицировать значения массива, связанного с этим поступающим ключом. Если не найдены - сообщение об ошибке отсутствия искомого элемента,
д) вывести в новый текстовый файл все значения переработанного Hashtable, преобразуя их в принятый в txt формата.
Если же искать надо в JTable - это уже GUI, а оно у Вас уже есть.
Распишите задачу яснее и, если требуется простое решение, типа консольного приложения, то реализовать его можно быстро и просто. И без денег.
P.S. Вряд ли проблема "больших данных" тут возникнет, если уж ввод новых данных осуществляется вручную.
@Mnobody: Понятно. Видимо, одна библиотека и для чтения и для генерации PDF. Это логично и рационально. В PNG мульти-стрипов не бывает. Хотя мульти-срезы можно организовать. Как превью для разного масшатаба. Тоже и с JPG. Но базовый растр (1:1) всегда один. Поэтому его и считывают стандартные Java либы всегда хорошо.
Вы упомянули просто TIFF , а это самый навороченный формат. Для научных целей созданный. И мульти-стрипы там есть. Вернее - тайлы. Хотя стрипы - тоже, как тайлы шириной во весь растр - чаще. Поэтому и решил прописать своё небольшое видение :o)
Но понимаю, что вопрос был не в этом. Хорошо, что всё решилось, и решилось просто - это главное.
Вопрос не понятен. Буквально, по тексту, Вы хотите из самого класса B (не его экземпляра, раз это не указано) вызвать непонятного типа и параметров функцию printText.
Этого маловато для ответа. Специфицируйте требования к printText и условиям её вызова.
Или просто унаследуйте B из A, и обеспечьте доступ к внутреннему JLabel.